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ABSTRACT 


While the cost of computing hardware has decreased steadily, the cost of software 
design, development and, maintenance has increased. One approach to reduce the cost 
of software development is rapid prototyping. Further, it has been proposed to combine 
the design strategy of rapid prototyping with a computer aided software prototyping 
system. Such a system would allow the software designer to employ a software base of 
reusable program modules. It would assist in prototyping and would automate a large 
part of the development effort. An important component of the automation would be 
a language translator facility. This translator would allow the designer to develop a 
software prototype in a high level specification language which would be simple and 
convenient to use and would translate the specification statements into an executable 
software language. 

This thesis demonstrates the feasibility of using a language translator by developing 
a prototype translator for a computer aided software prototyping system. The translator 
is Written in Attribute Grammar (AG) language and translates software specifications 
stated in the Prototype System Description Language (PSDL) into computer executable 


code in the Ada language. 
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]. INTRODUCTION 


A. COMPUTER AIDED PROTOTYPING SYSTEM 

A computer aided prototyping system (CAPS) has been proposed which would 1m- 
plement many ideas for improving software productivity [Ref. 1: p. 68]. Figure 1 on 
page 2 illustrates the proposed architecture of such a system. This architecture is de- 
signed to be implemented in an automated environment, the rapid prototvping schema. 
The automated environment will make it practical to develop, test, and quickly modify 
prototypes of a proposed system. It will make possible the demonstration of a working 
system (or perhaps several) to the customer in order to firm up requirements and func- 
tional specifications. 

1. Major CAPS Components 

The CAPS architecture consists of six major subsystems. The central objective 

of the system is to optimize the use of the programmer s time in prototype development. 


The objective of prototype development is to: 


ə provide a firm set of requirements and functional specifications which will guide 
development of the production software. 


* ensure agreement between customer and developer as to the requirements and ex- 
pected performance characteristics of the system 


e generate a modular, skeletal structure of the software system which will serve to 
guide further implementation 


e shorten prototype development time and thus accelerate production system delivery 


* assist in estimating the ultimate development costs of the finished system 


The CAPS allows the designer to enter a specification-based description of tie 
proposed system in a high level language constructed especially for prototype develop- 
ment. These specifications are acted upon by a rewrite subsystem and an cxecution 
support subsystem. The rewrite subsystem converts the specification statements into a 
normalized form. The normalized statements are used to search a software database of 
reusable components which are then provided to the execution support subsystem for 
instantiation in the prototype. The specifications are also acted upon by the execution 


support subsystem to produce executable code into which the reusable software modules 
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Figure 1. Computer Aided Prototyping System Architecture (CAPS) 


are instantiated. The resulting prototype can then be tested for conformance to specifi- 
cations and proper operation. New versions or redesigned versions can be quickly con- 
Stmeted amdetested as tne meediamiscs: 
2. A Prototype Language 
The core of the CAPS is the Prototype System Description Language (PSDL). 
It is optimized for use at the specification and design level of programming. Special 


structures exist for describing real-time svstems. A PSDL description represents a system 


as Operators communicating via data streams. The structure of the language encourages 
modular design of the prototype and by extension the eventual production version. 
more dctailed examination of PSDL will be undertaken in Chapter 3 of this paper. 
3. Rewrite System 

The rewrite system examines the PSDL file and produces a normalized version 
of the specifications which is used to search the software base for appropriate compo- 
nents. If no component is found, the designer may examine the module to see if it can 
be decomposcd into more primitive modules. [fit can be, then the new modules are 
Seeenicd in PSDL, the specifications are normalized, and the search is repeated. If 
no modules are found and the modules cannot be decomposed then they must be hand 
coded in tlie executable language. When modules are found in the software base, thev 
are provided to the execution support subsystem for instantiation in the prototype pro- 
eram. The functions of managing the database, searching it for appropriate modules, 
and calling forth those that are found is the province of the Software Design Manage- 
ment System. Currently a special Object-Oriented DBMS is being developed to meet the 
meeeial requirements of the SDS (Ref. 2]. For present testing 1t may be necessary to 
employ a commercially available database, though none currently meets the special re- 
quirements of this svstem. [Ref. 1: p. 70] 

4. Execution Support System 

The Execution Support System (ESS) consists of three interrelated parts, one 
of which 1s the subject of this paper. Figure 2 on page 4 illustrates the relationslup be- 
twecn the components of the ESS. Each clement of the system and its function will be 
bricfly described. The Translator design will be developed in Chapter 3 and 4. 

a. Translator 

The Translator (TL) converts PSDL source code into Ada®! source code. 

Output from the TL is provided to the Ada compiler/linker along with some additional 
information from the Static Scheduler (SS) to produce Ada object code. The object code 
Is then exported to the operating system and can be run for test and demonstration 


purposes. The TL passes real time constraints through without translation. The TL 


1 Ada is a registered trademark of the United States Government, Ada Joint Program Office. 
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Figure 2. Execution Support System (ESS) structure 


creates code to implement the operators as procedures which will be called by the main 
subprogram/schedule created by the SS. The TL is responsible for instantiating a ge- 
neric package which models the data stream bulfers between operators. The TL also 
ensures that all operator triggering conditions are encoded correctly, and that the Trig- 


ger data type and the Exception data type are properly encoded for the final model. 


b. Static Scheduler 

The SS examines the PSDL source file to locate all modules having reai- 
time constraints, and to determine if any special precedence relations exist among the 
modules. The SS then generates the necessary Ada code to implement the timing con- 
straints and the precedence relationships. The SS also generates the main subprogram 
or task. The SS finallv generates a schedule of operation for the program which takes 
into account the worst case time schedule for all modules that have critical, real-time 
constraints such as maximum execution time, minimum calling period, and minimum 
response time. This information is encoded into the modules to enforce timing con- 


Siaimes @C run time. Figure 3 illustrates the action of the SS. Janson [Ref. 3] and 


O'Hern [Ref. 4] have studied the conceptual and initial empirical investigations into the 


design and implementation of the SS. 
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Figure 3. Static and Dynamic Schedule Schema 


c. Dynamic Scheduler 

The Dynamic Scheduier (DS) operates at runtime along with the prototvpe 
model. It is designed to control the execution of all non-critical operators within the 
program. A non-critical operator is one which is not subject to hard real-time con- 
straints. The DS is invoked each time there is spare time within the static runtime 
schedule created by the SS. At that time DS commences execution of the next available 
module in its set of operators and continues to invoke non-critical modules until the 
available time is exhausted. At that point, operation of the DS ts interrupted and con- 
trol is returned to the SS to continue the time critical operations. Figure 3 on page 5 
shows the relationship between the DS operation and the SS operation. Eaton [Ref. 5] 


has exa, mod the conceptual and fundamental design issues for the DS. 


B. CENTRAL AIM OF THIS PAPER 

in order to approach the development of the proposed CAPS architecture on a 
sound basis, it 1s necessary to consider the important theoretical ideas on which the ef- 
fort will be based. The key literature which made possible the effort to produce this 
prototype translator will be reviewed. The reader mav also wish to consult additional 
references cited in the bibliography. Many of the materials therein provide insight into 
the difficult problems of improving productivity in software engineering through auto- 
mated means, and of configuring software systems to address real-time constraints on 
system performance. 

]he purpose of this paper is to demonstrate the feasibility and functionality of an 
automated language translation facility which can be coupled into a larger, integrated 
svstem for automated software prototyping. This translator will receive as input a 
source file in PSDL which specifies the system to be prototyped. It will produce as 
output, source code in the Ada language which will be compiled and exported to the 
operating svstem. Discussion of the ratronale for choosing PSDL and Ada for use ina 
prototyping environment will be presented in Chapter 3. Architecture and design of the 
translator will be developed in Chapter 3. This study will be limited to producing a 
translator capable of recognizing the full PSDL syntax and producing, at most, rudi- 


mentary Ada output. This limitation rs imposed because a rigorous, formal definition 


of the relationship between Ada and PSDL has not vet been accomplished. Once such 
a definition i5 achieved, the results must be applied to the elementary translator created 
in the present effort. The resulting translator, combining a formally established re- 
lationship between the source and target languages with a translator which recognizes 
PSDL syntax, will meet the requirements of the CAPS architecture for a transiator ap- 
plicable to general cases. 

The present work is arranged as follows: 


Chapter 2 discusses the theoretical basis for the CAPS system and surveys previous 
research which lays the foundation for the present work. 


Chapter 3 presents the basic implementation approach to the translator construction. 


Chapter 4 presents some possible applications of CAPS research to the field of tele- 
communications. 


Chapter 5 presents conclusions and possible future avenues for research. 


lí. THEORETICAL UNDERPINNINGS OF CAPS 


A. HARDWARE AND SOFTWARE: A PROBLEM 

Several trends have become apparent in the computing industry. These trends have 
a significant impact on the field of software engineering. The first of these trends 1s the 
expansion of computer usage into an ever widening arena of applications. Early digital 
computers were largely confined to military, goveriunental, and research applications. 
A relatively small population of users was affected by the computer. Today the com- 
puter is a significant feature of everyday life for almost the entire industrialized world. 
Few governments or businesses function without the aid of computer systems. Com- 
puter systems route our telephone calls and record our bank transactions. Military 
forces worldwide employ computers for handling record traffic and a variety of com- 
mand and control functions, as well as many tactical applications. 

One study estimated that forty percent of the U.S. labor force relied on computers 
in performance of their daily work during 1985. Another barometer of the growth in 
demand for computing is the percentage of the Gross National Product (GND) that it 
represents. It has been estimated that the total amount spent on all aspects of com- 
puting in 1980 was approximately 5 percent of GNP or about S130 billion. It 1s expected 
that this will rise to as much as 12.5 percent of GNP by 1990 |KRet oo 

Another trend, is the increasing power of each new generation of computing ma- 
chines and the corresponding decrease in relative cost for a machine of that power. The 
cause of this trend is found in improved engineering and production methods for tran- 
sistors and integrated circuits. The advent of Large Scale and Very Large Scale Inte- 
gration (LSI, VLSI) have made possible great improvements in computing hardware 
architecture and lower costs of production. Each new generation of computing ma- 
chines has benefited from engineering and production knowledge gained in previous 
generations. Today's machines are more reliable and robust in performance than their 


predecessors. 


The decrease in hardware costs and increasing demand for computing services has 
generated a third trend in the industry. There is an increasing cost of software devel- 
opment and maintenance as compared to the costs -of hardware, and there is an in- 
creasing cost of software as a total fraction of computing costs. Figure 4 on page 9 
shows the changing ratio of expenditures for hardware and software over time [Ref. 7]. 
The figure should not be interpreted as applving to anv specific system. Instead, it re- 
presents the general trend within the industry, that software development and especiallv 
maintenance represents an increasingly large portion of the cost of computing. The shift 
in resources to software maintenance arises from several considerations. There is more 
and more software to be maintained so a correspondingly larger number of persons are 


required to perform maintenance functions. 
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Figure 4. Changing hardware/software cost ratio 


Mills [Ref. 8: p. 267] points out that in only 25 years of software developinent his- 
torv, some 75 percent of data processing personnel are taken up with maintenance, not 
development. lle states two reasons for thus. One 1s logistic and the otlier a teclinical 
reason. The logistic reason is that systems are maintained midefinitely after a defiute 
period of development. Each time a development is completed some fraction of the 
work force must be diverted to maintenance. Mills [Ref. 8: p. 267] demonstrates that, 
for a constant work force working for a long period of time, the 75 percent fraction 
devoted to maintenance can be predicted. Ile states that only the purging or replace- 
ment of older applications keeps the figure below 100 percent. The technical reason is 
that it has proven more difficult to develop correct and capable svstenis in the first place. 
The ability to integrate and debug systems has been consistently underestunated. Time 
after time software systems are late in delivery and do not do the things the users ex- 
pected them to do. Also, there have consistently been underestimations of the uncer- 
tainty and change facing software applications. For both these reasons, a large work 
force 1s required to do both corrective and adaptive maintenance to keep the application 
softwareduncnemnpe ier a po 

Another aspect of maintenance is what we mean bv that term in the software in- 
dustrv. Maintenance of software systems does not sunply mean corrective maintenance 
in the strictest sense. Carrio [Ref. 9: p. 19] lists many other activities which are often 
encompassed by the term, including: 


e Enhancing the system (“gold-plating”) in ways that do not alter the core require- 
ments of the system 


e Adding new or substituting other requirements for performance relative to those 
implemented (often the result of a poorly defined requirements set at the beginning 
of development) 


* Changing the baseline performance level to expand the performance envelope or 
due to expected changes in doctrine-optinuzation 


® Changing baseline requirements due to a planned evolutionary development of the 
system 

Mills [Ref. 8: p. 267] humorously describes the terms “debugging” and “rmainte- 

nance” as euphenusms in the software engineering world. Debugging is the correction 


of errors in the program which were originally put there by the programmers. 


10 


Maintenance is the restoral of the program to a correct state of operation; but the 
program was never correct in the first place. The point he aims at is that proper soft- 
ware design and engineering techniques are required to achieve maximum productivity 
and quality software svstems. 

Beohm [Ref. 10] estimates that in 1980, the cost of software for computer man- 
ufacturers, user organizations, and software firms was $40.2 billion dollars. This 
amount represented 84 percent of the total budget spent on computing hardware and 
software. As seen in Figure 5, software may account for 90 percent of the amount 


spent on computing svstems bv the 1990's (Ref. 11: p. 49]. 
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Figure 5.  Harware/Soitware cost trends 
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The rising costs of software have been well documented in DOD. In 1975. solum 
costs represented over 46 percent of the total DOD software budget [Ref. 12: p. 14]. 
It has been noted that DOD experienced a 51 percent increase in the direct cosmos 
computing systems, in spite of dramatic declines in the cost of hardware 
Metal fo Sr 

Unfortunatelv, productivity in software engineering has not kept pace with the 
erowth in demand for computing systems and software applications. This 1s graphically 


illustrated in Figure 6 (Ref 14]. 
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Figure 6. Software suppiy and demand trends 


The figure shows that growth in demand for qualified software personnel is growing at 
a rate which outstrips their availability. Furthermore, the growth in productivity among 


software personnel also lags demand. It has been estimated that the average 


programmer, in the absence of modern programnung methods, can produce six to ten 
lines of debugged code per day. This is influenced bv a variety of factors ranging from 
programmer competence to the number of persons working on a project and the purpose 
for which the program is written. Tairley [Ref. 15: p. 17] states as a rule of thunb, 
that typical productivity levels for a programmer on a per day basis as a function of task 
complexity are: 

o less than one line per day for systems programming 

o 5to lO lines per day for utilitv programs 


9 25 to 100 lines per day for application programs 


Itis a truism that, in general, a computing system ts only as capable and reliable 
as the software employed m the system. In an age of incredible advances in hardware 
technology, the computing industry is liampered by slow gains in productivity in soft- 
ware engineering. Various sources of this situation have been cited... One element is tlie 
relative youth of the software engineering discipline in comparison to other engineering 
fields. Only three decades of experience and study support software engineering. These 
have been three decades of momentous change. The early leaders of the computing 
revolution were not native to the field. There has been a great deal of learning "on the 
job" for most software engineers. Until barely ten years ago there was a lack of rigor 
associated with program development and software engineering. As time has passed 
software engineers have recognized the need to develop a more rigorous approach to 
programming [Ref. 8: p. 268-269]. Even the relatively young field of electronics engi- 
neering is founded in the ngor and discipline of centuries of physical science and 
mathematics. 

Another problem las been the failure to recognize the importance of human com- 
munication to the discipline of software engineering. Computing is a human endeavor, 
in support of human needs. Humans must be able to communicate those necds to the 
system developer, who in turn must express an answer to those needs in the computing 
system. If there is any failure of communication by either party the result will be a 


system that fails in one degree or another to meet the requirements of the human user. 
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These trends lead us to conclude that soine effort must be inade to achieve greater pro- 


ductivity and effectiveness in software engineering. 


B. THE TRADITIONAL “WATERFALL LIFE CYCLE” 
]. Characteristics 

The traditional method of software engineering is the “waterfall life cycle.” 
Figure 7 on page 15 shows a graphic representation of this approach. Under this 
schema, the customer perceives a need for a computing application for his operation 
or organization. He approaches a software developer and describes lus problem. After 
some negotiation, the software developer determines what he believes the user’s needs 
are and an agreement is reached to produce a computing vackage to meet the need. 
Contracts are let and the developer converts the customer’s statements of need into 
precise (hopefully) functional specifications which can be implemented by the program- 
mers. An architectural design is established based on some method of data flow or 
control flow. The system is then parceled out to programmers in manageable modules 
which each programmer is free to implement. As modules are developed they are as- 
sembled. When the system is complete then full scale testing and debugging of the sys- 
tem begins. If the system tests satisfactorily, the job is done and the system delivered 
to tlie customer for acceptance. Then begins the cycle of system maintenance. If the 
system fails or has numerous bugs (as is invariably the case with large svsienis) or if the 
system does not meet the functional specifications, or, worse, does not function as the 
customer expected, then the svstem must be restructured in various ways to correct tlie 
problem. This can be very costly, especially since tremendous amounts of manpower 
will have been already been invested at this point. 

2. Difficulties With The Traditional Approach 

Carrio [iXef. 9: p. 17] describes this life cycle as a three phase event consisting 

of: 
S conceptual and definition phase ( the requirements analvsis phase) 
e development phase (from functional specifications through test system) 


* deployment and operational phase (maintenance and support) 
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Figure 7. Traditional “waterfall” approach to the software lifecycle 


He points out that the problem with this approach is the lack of interaction 
between the keepers of doctrine (the customers) and the developers in the early stages 
of the life cycle. Phase one is the province of the users. Phase two belongs to the de- 
velopers and their supporting programmers and subcontractors. Then in phase three the 


two groups begin to interact in earnest. The key difficulty with this life cycle is 
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communications -- tlie ability of the user and developer to cominunicate, understand and 
insure the integrity of the initial set or requirements. The quesuon of whether the "as 
specified,” the “as designed,” the “as tested,” and the “as built” systems are all the same 
must be asked again and again. Under this life cycle the answer is no [Ref. 9: p. 19]. 
Frequently this life cycle approach has led to cost overrun, late product deliverv, and 
failure of the “as delivered” system to meet the needs of the customer. [t may be con- 
cluded that the traditional life cvcle is one source of difficulty in the struggle to achieve 
greater effectiveness and productivity in software engineering. 

Several techniques have been proposed to improve upon the traditional life cy- 
cle. First of all, a rigorous design phase, in which customer requirements are exhaus- 
tively examined to produce a firm set of 'uicztional specifications which accurately reflect 
what the customer wants. These are used throughout the remaining fe cycle e 
standard for system development. Second, the use of prototyping in an automated en- 
vironment to provide guideline inodels for the entire life evele. Use of automated toois, 
Al/ Knowledge based systems, and various application support environments to aid the 
software engineer in developing, documenting, and maintaming the system 
[Ref. 9: p. 20]. This would be coupled with top down development and a structured 
approach to design to enhance system maintainability and reliability 


[Ret. 8: pp. 269-271]. 


C. RAPID PROTOTYPING 
l. Description of Rapid Prototyping 

An alternative to the traditional approach is rapid prototyping. Under the rapid 
prototyping paradigm, an effort is made to ensure that the custoiner and the developer 
both understand what the customer's requirements for a software system are. This 
schema 1s graphically illustrated in Figure 8 on page 17. In this approach, there is 
again a period of discussion with the customer to determine his requirements. The re- 
quirements are used to generate functional specifications. With the functional specifi- 
catious, a prototype of the intended system is constructed and demonstrated for the 
customer. At this point the customer can decide if the prototype reflects the type system 


he had in mind; and the developer can see whether his perception of the customer’s 
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Figure 8. Rapid prototyping approach to software engineering 


requirements was correct. Any adjustment needed in the functional specifications are 
made, the prototype system is recoded to reflect the adjustments, and the system is 
Once again demonstrated. This process is repeated until the prototype behaves as the 
‘customer and the developer expect. Full scale development of the system is commenced 


Once prototyping is completed. [Ref. 16] 


IE 


2. Objectives of Rapid Prototyping 

The iterative, rapid prototyping approach accomplishes several goals. First, 
it insures accurate communication between the customer and the developer. Due re- 
cognition to the difficulties of human interaction is given. The customer certainly knows 
his profession and has a clear mental picture of what he wants to accomplish with a 
computing system, but may not understand computing systems themselves. The soft- 
ware engineer understands computing systems but may not understand the world of the 
customer. They are both speaking English but may have no idea what each other is 
saying. Rapid prototvping secks to cut through the communication difficulty by pro- 
viding an executable model of the intended system which the customer can see. The 
customer will usually be able to recognize whether a working software system performs 
as he expects. This will ensure a stable set of requirements is achieved early in svstem 
development. [Ref. |: p. 71] 

Prototype construction aims to make efficient use of the designer's time. As 
such it differs from production software in which the goal may be driven by the need to 
optimize speed, or memory usage, or accuracy and ease of use. Production software 
Is designed to be fault tolerant and capable of handling a wide range of error conditions. 
The prototype may not be fault tolerant at all. In all probability, it will not be opti- 
mized in performance. Prototyping the system generates a skeletal design framework 
which may serve as the initial design structure of the production version (Ref. 1: p. 71]. 
The early prototypes provide a traceable link between requirements, design, imple- 
mentation and maintenance [Ref. 9: p. 20]. The use of prototypes aids in feasibility 
studies. Varrous methods of implementing portions of the system can be tested and the 
more promising methods can then be selected for implementation in the production 
system. Finally the prototvping approach aids in cost estimation. The cost of the final 
system will often be proportional to the final cost of the production version. 


[Reca 
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D. IDEAS FOR INTEGRATED, AUTOMATED PROGRAMMING 
ENVIRONMENTS 
In his ACM award winning dissertation, Generating Language Based Environments, 
Thomas W. Reps (Ref. 17: pp. 1-2] raises many salient issues regarding software engi- 
neering and software productivity. He observes that much of software development re- 


quires exhaustive attention to organizational detail. By this he means many things. 


Among them are: 
e the need to constantly be concerned with details of language syntax and semantics 
e the accurracy of program entry 


e the details of operating a series of software tools such as editors, 
compilers, linkers, debuggers, and library managers ( all in the proper order) 


* maintaining an audit trail of documentation for the svstem 
under development 


« the necessity to communicate with others in the development process 


All the while the system developer or programmer also hopes to períorm creative 
intellectual work, yet it comprises a small part of his daily effort. The remainder of his 
time is eroded away by the mundane details of the job. A similar observation has been 
made by Fairley [Ref. 15: p. 12-13] and Brooks [Ref. 18: p. 16-18]. Reps goes on to 
point out that much effort has been expended to make the progranimer's life easier; to 
shield him from the details and allow him to do creative work. The form of this help 
has characteristically been a series of automated tools such as editors, debuggers, parser 
generators and the like. These tools have provided some relief, and have aided pro- 
ductivitv. However, they have generated problems of their own such as: 

* learning to operate each of these independent tools 


e emploving the tools in the correct sequence when needed 


Worse, the individual tools are not normally integrated with each other to take full 
advantage of computing power now available, and to automate away the maximum 
amount of detail, leaving the programmer completely free to pursue productive creative 
endeavor. Reps argues that to make true breakthroughs in this area it will be necessary 


to create an automated design environment incorporating all necessary tools under one 
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coherent interface. Ife contends that such a system would be optimized to the particular 
language for which it is designed. This would be achieved by designing an integrated 
enviromment which “understands” semantics of the programming language being used 
In it. 

Reps then presents the development of a Synthesizer Generator whose purpose 1s to 
generate language-based edtiors for different programming languages. The tool uses a 
specification of the display format, syntax, and static semantics of the language to be 
edited. The objective is to create an editing environment which will prevent entry of 
incorrect svntax while the programmer is editing the program. The primary concern of 
the Reps dissertation is developing a framework for the semantic component of the 
language based editor. [Ie discusses various methods to generate a programming envi- 
ronment from an attribute-grammar description of a language. Reps also discusses what 
attribute grammars are and discusses several algorithms for attribute evaluation. Ife 
then shows how the semantic component of a language-based editor can be developed 
from an attribute grammar description and discusses some of the problems created by 
using attribute grammar based development systems, chief of which 1s the extravagant 
use of storage resources. [Ref. 17: p. 4] 

Several 1deas in Reps work have impact on the design features envisioned for the 
CAPS. These include: 


e incorporation of an “intelligent” editor environment which will aid the program 
designer in entering the prototype description correctly 


ə integration of all the tools neccessary for program prototyping under one colerent 
interface. 


e use of attribute grammar based approaches to language description. 


There are similarities and differences in what Reps does and in what 1s aimed for in 
the CAPS generally and in the Translator in particular. Reps is specifically concerned 
with development of editing environments based on attribute-grainmar descriptions of 
a language. CAPS is concerned with incorporating an intelligent editor along with nu- 
merous other tools in order to remove a great deal of the mundane drudgery from soft- 


ware development. Reps uses attribute-grammar approaches to develop editing 


environments. In this thesis, an attribute grammar based tool is used to develop a 
translator which can convert PSDL into Ada. 

Reps’ work sets a direction for future programming development environments. It 
helps reveal a promising application for the concept of attribute-granmars. It demon- 
strates the practical application of important theoretical concepts to the problems of 


productivity in software engineering. 


E. DESCRIPTIONS OF A COMPUTER AIDED PROTOTYPING SYSTEM 

A general description of a CAPS is provided in two papers. First is the technical 
report, A Computer Aided Prototyping System, by Luqi and Ketabchi (Ref. 1]. Second 
is the technical report, Research aspects of Rapid Prototyping, by Luqi[Ref. 16]. These 
papers describe the overall concept of a CAPS. They lay out an architectural design for 
such a system and provide a starting point for the research in this thesis. 

The CAPS would provide an integrated environment for the development and test- 
ing of prototypes of software systems. It would be specifically designed to address sys- 
tems which were large, embedded, and had hard, real-time constraints. It would make 
use of the Ada language, and would employ a database system to store and recall both 
reuseable software components in the Ada language, and previously designed proto- 
types in the PSDL language. A system to automatically translate the PSDL descriptions 
of a system into Ada code and conipile them so that they could be executed to demon- 
strate the prototype would be provided. The CAPS would be based on two ideas which 
would establish the fundamental character of the system. One is the methodology of 
rapid prototyping, the other is a language (PSDL) specifically designed for writing 
prototvpe designs of systems with hard, real-timie constraints. PSDL would give ex- 


pression to the methodology of rapid prototyping and form the core of the CAPS. 


F. IHE PSDL LANGUAGE AND RAPID PROTOTYPING 

The central paper on the PSDL language and the application of the rapid proto- 
typing methodology is Luqi's Ph.D. dissertation, Rapid Prototyping For Large Software 
System Design (Ref. 19]. Four related papers have been published which provide similar 
detail on the nature of PSDL and rapid prototyping. These are: 


o A Prototyping Language for Real Time Software [Ref. 20] 
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o Rapid Prototyping of Real-time Systems [Ref. 21] 
e Languages for Specification, Design, and Prototyping (Ret. 22 


o Execution of Real-Time Prototypes [Ref 23] 


The Execution of Real-Time Prototypes paper is a short technical report prepared for 
the Naval Postgraduate School. It very briefly summanizes tlie concept of CAPS and the 
rapid prototyping methodology. The remaining papers are closely related in content and 
purpose to one another, and are separated by the depth to which they examine the 
subject from the technical report. 

The seminal paper among the remaining papers is the Luqi Ph.D. dissertation. The 
paper begins by introducing the PSDL language. An extensive discussion of the CAPS 
system is set forth. The various components of the PSDL language are presented. The 
application of rapid prototvping to a system developed using PSDL is discussed in some 
detail. There is a brief discussion of the implementation of various PSDL language 
components within the ESS, and a discussion of the functions of the SS, DS, and TL. 
An example of a PSDL prototype 1s presented. Finally, a summary of PSDL syntax in 
BNF form is provided. 

The BNF summary of PSDL syntax 1s included as Appendix A of this thesis. From 
the standpoint of translator design, the most important sections of the dissertation, are 
section 2, on PSDL language elements and the discussion, in section 4, on how certain 
PSDL elements might be implemented by the Translator. Since the objective of this 
paper is to develop a Translator, section 4 of the Luqi dissertation provides the foun- 
dation for chapter 3 and 4 of this thesis. 

Two of the papers are available in published journals. The paper, 4 Protoyping 
Language for Real-Time Software (Ref. 20], 1s essentially a reprise of the information 
presented in the Luqi thesis, without the BNF diagrams for PSDL. The paper presents 
a detailed description of PSDL and its employment under a rapid prototyping para ommi 

Rapid Prototyping of Real-Time Systents [Ref. 21] presents an abbreviated discussion 
of PSDL and its use in a rapid prototyping setting. Less emphasis is placed on the 
specifics of PSDL syntax and language elements, and more on the general model aud 


concepts involved in employing PSDL under the rapid prototyping methodology. The 
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paper serves as an excellent introduction to the fundamentals of PSDL and rapid pro- 
totyping in the CAPS environinent. 

Languages for Specification, Design, and Prototyping (Ref. 22], is an extensive 
presentation of the current state of language development in the three separate areas of 
specification, design, and prototvping. The authors distinguish between the three goals 
and discuss the characteristics of a languages aimed at satisfying the demands of each 
of the particular areas. Discussions and illustrations of various currently available lan- 
guages are presented. The paper is an excellent general discussion of issues involved in 
selecting a language for a particular purpose. The paper points up the different prob- 
lems associated with cach approach to software production and demonstrates possible 
solutions. PSDL is presented as a good general purpose language for specification, 
design, and prototyping. PSDL has many features which make it convenient for usc 
with Ada including: 


* is an executable language construction unlike many specification or design lan- 
guages which are not 


* supports a modular approach to program design. 
® supports data, control, and operator abstraction 
* supports exception handling, separate compilation of generic units, and use of 
reuscable components. 
G. ATTRIBUTE GRAMMARS AND TOOLS 
The objective of this thesis 1s to generate a translator which will read a PSDL source 
file and produce and Ada source file. This might prove a daunting task were 1t not for 
the availability of an automated translator generator tool called Kodivak [Rcf. 24], The 
Kodiyak system requires as input, an attribute grammar (AG) description of tlic source 
language. It is proper to consider some literature which addresses AG's in general, and 
the Kodivak in particular. 
i. Attribute Grammars: What Are They? 
The classic work on AG's, is Semantics of Context-Free Languages 
B »». 127-145. The paper sets forth “ ... a teclinique for specifying the 
“meaning” of languages defined by context-frec grammnars ..... [Ref 25: p. 127] It 1s 


assumed that the language is “context-free”. That is, the “meaning” of any string or 
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element in the language is independent of the context in which it 1s used. Thus is usually 
not the case for natural languages (c.g., English, et al.), but often is the case for pro- 
grunming languages. It is asserted that the “meaning” of any string in a context-free 
language can be determined ". . . by defining “attributes” of the svmbols in a derivation 
tree for that string.” [Ref 25: p. 127] If the production rules for a given language are 
known, it is possible to assign functions to each of the production rules which define 
the "attributes" of a given symbol or combination of symbols. The attributes may be 
developed in one or both of two ways. They may be “synthesized”, defined in terms of 
their descendants; or they may be “inherited”, defined in terms of their ancestors 
[Ref. 25: p. 128]. Colloquially, synthesized attributes are developed from the bottom 
up in the derivation tree, while inherited attributes are developed from the top down. 
Once all the attributes of all the symbols in the string are known, the “meaning” of the 
string is known. These simple but powerful concepts form the foundation of AG ap- 
proaches. Knuth presents an applicative example of these principles as the first part of 
his paper [Ref. 25 pp. 128-130]. The remainder of the paper is devoted to the math- 
ematic and formal properties of the technique, and another example of how the method 
can be applied to programming languages. Finally, Knuth compares his method with 
other known methods of semantic definition. 

For the purposes of this paper it is possible to summarize Knutli's work. First, 
suppose there 1s a language for which there are a set of production rules. PSDL is such 
a language, with a context-free grammar and a set of production rules in the form of 
BNF diagrams for the language. Then to determine the "meaning" of anv string con- 
structed according to those rules, it is necessary to: 

l. parse the string into its component parts and create a derivation tree of the string 


2. create a sct of functions (equations) which assign meaning to each of the compo- 
nents of the string 


3, reduce (determine the meaning of) the string based on the BNF rules and the 
meaning of each of the components 

The Kodiyak system allows the application of the technique in a practical and 

convenient fashion to real problems. Detailed discussion of the AG approach will be 


deferred to chapter four of this thesis. Suffice it to say, that AG's have been used for 


a varietv of purposes, among them, the construction of conipilers, prettv-printers, and 
translators. Knuth's short paper is at once the cornerstone and keystone of a whole arca 
of software engineering research. 
2. An AG Based Tool For Transiator Generation 

The effort required to produce a translator of the type desired for the CAPS 1s 
considerable. Fortunately, a tool has been developed which makes possible the auto- 
matic generation of translators. That tool is the Kodiyak systern. Kodivak is an AG 
based tool developed by Robert M. Herndon as a Ph.D. dissertation at the University 
of Minnesota [Ref. 24]. The Ph.D. dissertation provides exhaustive details on the tech- 
nical aspects of translator generation, the operation of AG based systems, and the de- 
sign and construction of Kodiyak. Another work on the Kodivak is AG: A Useful 
Attribute Grammar Translator Generator [Ref. 26]. Although it refers to an earlier ver- 
sion of the Kodiyak (then known as AG), it provides a useful description of the Kodivak 
system. The most useful work is The Kodiyak Reference Manual, which is an appendix 
to the dissertation [Ref 24: app. 1]. This is a detailed reference manual describing how 
to employ the Kodiyak to generate a translator. 

Kodiyak itself is ". . .a language designed for constructing translators 
[Ref. 24: p. 1, app IJ" Itis AG based. “The Kodiyak translator accepts a context-free 
grammar along with such attribute declarations and equations, a scanner specification, 
and output declarations, and generates the described translator 
[Ref. 24: p. 1, app 1].” Kodiyak works on many Unix%2 based systems. It requires the 
use of various resident utilities. A C library and compiler, the LEX (lexical analyzer) 
(Ref. 27] and the Yacc (yet another compiler compiler) [IRef. 28] must be present in or- 
der to use Kodivak. The system is very effective and is presently in use at this institution 
to develop a pretty printer, as well as the translator presented in this thesis. Itis pres- 
ently in operation on a Vax®3 11/785 and a Sun®+ 3/50 diskless workstation. The pres- 


ent translator is being developed on the Sun station. 


2 Unix is a registered trademark of Bell Laboratories. 
3 VAX is a registered trademark of the Digital Equipment Corporation. 


4 SUN is a registered trademark of Sun Microsystems Incorporated. 
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There are only a few significant difficulties with the present Kodivak. First, the 
system requires a great deal of storage, and a great deal of epu time. The translator 
listing for the CAPS, presented in appendix C, requires about five minutes to compile 
on the Sun station. This is a station dedicated to the translator work and is otherwise 
idle. On the Vax 11/785, with normal user loads, the same listing requires about 10 
minutes to compile. The five minute figure on the Sun station represents actual cpu 
tune. Second, the error messages and error handling in the system is not always as 
helpful as it could be. Error messages often refer to temporary files created by LEX or 
Yacc and not to the original source file. Also, when Kodiyak scans the input file, it 
may allow certain error conditions to pass through which will later be fatal during Lex 
cr Yaec scans. Typical of this type error is a mispelled variable name. So long as 
Kodivak finds correct syntax in the input file it will allow the file to be presented to Lex 
and Yacc for processing. A mispelled variable name will result in a fatal crash of the 
Yace scan and may be fatal to the Lex sean. Ideally Kodiyak should trap any errors of 
this tvpe and exit immediately so that the user can correct the problem before the time 
consuming LEX and Yacc scans begin. Nevertheless, Kodivak 1s powerful and signif- 
icantly eases the effort required to construct the translator. 

The Kodiyak operates by taking an input file which is an AG description of the 
input language and the attribute equations which relate the input language to the output 
language. After scanning the file to insure it is in correct Kodiyak syntax, the file is 
passed to Lex and Yace for processing. The end result is an executable translator, 
compiled in the C language. This translator can accept textfile input and will produce 


textile output 


di. IMPLEMENTATION AND DESIGN CHOICES 


A. CAPS 
Prototype System Deseription Language (PSDL) provides the backbone of the 
CAPS for design and specification, while Ada was chosen as the language for unple- 
mentation. The basis for this ehoiee 1s found in the eharaeteristics of the languages 
ehosen. Each offers advantages and disadvantages for the design, speeification, and 
implementation of hard real-time, large, and embedded systems. Alone, each presents 
difficulties in use. Used together in CAPS, the two languages experienee a symbiosis, 
whieh results in flexibility, power, and ease of use for the system developer. The same 
power, convenience, and ease of use are available for the development of CAPS itself. 
]l. Implementation Questions for CAPS 
CAPS is under development and not yet fully implemented. This paper aims to 
demonstrate a working prototype for the CAPS translator. Several other papers are in 
progress which specifieally address other aspeets of the system. The capabilities envi- 
sioned for CAPS are extensive. 
@ How ean it achieve them? 
® What is the foundation of the systein? 
e Why is that choice of foundations better than others? 


e Why is Ada not sufficient in itself to aehieve hard, real-time system design and 
implementation? 


o What are the general properties of real-time systems that demand a tool like CAPS? 
These questions and others form the basis of this ehapter. 


B. FOUNDATIONS FOR CAPS 
1. Prototype System Description Language (PSDL) 
PSDL is the foundation on which CAPS 1s being built. Itis a language designed 
to support eonstruction of large and embedded systems and those bro hard, real-time 


constraints. 
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a. Embedded and Real- Time System Properties 


Embedded and hard real-time systems have several general properties which 


place special demands on the designer and his language tools. These properties are: 


l. 
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Often large, running to millions of lines of code and thousands of modules 
Often operated in a multiprocessor environment 


Under the DOD concept, their primary function is often not computing but con- 
trolling or monitoring the operation of complex or safety critical systems 


Generally have requirements for high reliabilitv, and penalize the user severely 
upon failure (loss of aircraft and crew, loss of control of critical manufacturing or 
industrial process, etc.) 


Expect to be emploved over an extended lifetime, with periodic updates and mod- 
ification to maintain currency 


Are too large for a single individual to understand or program alone but require the 
efforts of teams of programmers and maintenance personnel 


Often require hard, real-time constraints in operation (1.e., operational schedules 
and deadlines within the program in response to real world conditions) 
[Re Ep 13-10] 


These characteristics demand several features of a prototyping language 


which are summarized as follows: 


L. 


r3 


Il au 


6. 


Should have a simple computational model which limits and exposes the inter- 
actions betwcen modules and is consistent with the prototyping methodology 


Should produce executable prototypes 
Should be simple and easy to use 


Should support hierarchical design to simplify construction of large, complex sys- 
tems 


Should apply at both specification and design phase, thereby providing a unified 
notation to the user 


Should provide specifications suitable for retrieval of reuseable modules from a 
software base 


Should support data abstraction, control abstraction, and function abstraction 


Should contain abstractions which can be used to construct real-time systems 
[Scr 19 NI 
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b. Why Use PSDL? 
PSDL and Ada both approach the design of software in the same manner. 
There are several advantages to employing PSDL in the CAPS over using Ada directlv. 
First, PSDL is a much simpler language. Its grammar (see Appendix A) Is verv small, 
compared to the Ada grammar which is very large. The compactness of PSDL allows 
its use as a tool with which to search a software base by automated means for previously 
written modules which will implement the designer's objectives. The designer does not 
need to know what units are available. The CAPS will search for Ada components in 
the software base for him, and will incorporate them into the prototype as long as they 
match the PSDL description. Second, CAPS will use the PSDL description to produce 
a graphic representation of the prototype program's hierarchical structure. PSDL is a 
distillation of the Ada language’s constructs. Tlurd, the CAPS translator will automat- 
ically generate interconnections for Ada procedures to implement PSDL operators. 
c. PSDL Computational Model 
PSDL supports the specification and design of hard, real-time and embed- 
ded systems with a simple and executable computational model. PSDL inodels software 
svstems as a set of OPERATORS communicating via DATA STREAMS. The formal 


computational model is an augmented graph: 
G = (V,E,T(v),C(v)) 


where: 
* V is the set of vertices 
Eae is the set of edges 
e T(v) is the maximum execution time for each vertex 


*. C(v) is the set of control constraints for each vertex v 


Each vertex represents an operator while each edge represents a data 
stream. Components V, E, and T(v) are called the ENHANCED DATA FLOW 
DIAGRAM. [Ref. 19: p. 11) 


Do 


2. Major PSDL Language Structures 
a. Operators 

In PSDL, Operators may be either atomic or composite. Composite oper- 
ators can be decomposed into two or more operators, each of which may be composite 
or atomic. Atomic operators cannot be decomposed into simpler components. llus is 
a colloquial rather than formal distinction. It envisions a hierarchical breakdown of the 
system into logical coniponents which are as simple as possible without becoming trivial. 
No special rules for decomposition are imposed. Thus distinction allows the modeling 
of hierarchically structured programs as sets of operators. Operators at higher levels in 
the program structure are composite wlule those at the lowest level of the program 
structure become the @toruc operators. PSDL can therefore be used to support top 
down design strategies. 

A second classification considers that operators may be data driven or pe- 
riodic. Under this schema, the firing of a data driven operator is accomplished due to 
the presence of data in its input data stream(s), while the firing of a periodic operator 1s 
dependent upon timing constraints which must be met during program operation. The 
data driven operator allows the modeling of svstems which utilize data flow as a means 
of control instead of the more traditional timing control in real-time systems. In eitlier 
case, when an operator fires, it reads one data object from each of its input streams and 
writes, at most, on object to each of its output streams. 

A third classification of operators 1s allowed. An operator may be eitlier a 
function or a state machine. This description relates to the values output from the op- 
erator. [he output value of the function tvpe operator is dependent solely on the cur- 
rent set of values present on the input streams to the operator. The output of the state 
machine type depeuds, not only upon the current set of input values, but also on the 
values of a finite number of state variables internal to tlie operator. Figure 9 on page 
31 illustrates several aspects of the LSD creer itomcom cer 

Each of the preceding operator classifications can be directly related to ex- 
isting concepts in Ada. Ada supports both top down and bottom up design strategies 
in a hierarchical, modular program structure. PSDL allows tlie description of each 


module as an operator. In Figure 9 on page 31 A is an operator with one input stream, 
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Top level OPERATOR 
as a function 


Second level 
decomposition 


CC is a STATE MACHINE 





Figure 9. Various types of PSDL operators 


a, and one output stream, e. [n this case A is a function since no state variables are seen. 
A is also a composite operator which can be decomposed into three operators, BB, CC, 
and DD which are atomic operators (they are not or cannot be decomposed further). 
In this representation, CC is a state machine, since it has state variable, found on data 
stream d, which is combined with the value on its input stream, b, to generate the output 
Value on data stream c. 

At the lower level of decomposition, A still exists, but is represented in 


greater detail by the three atomic operators and their associated data streams. The input 
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data stream to BB is a’. The data type and value found on a’ will be the same data type 
and value found on a, and similarly for e and e”. Tluús structure is analogous to an Ada 
program being composed of one or more subprograms. [or example, we might use an 
Ada procedure to represent A. This procedure might contain three Ada subprograms 
(functions or procedures) which are called within it to implement A. Procedure DD 
would produce value which would be passed to A onan output parameter of DD. This 
would be passed out of A as a value on an output parameter of A. In Ada, each of the 
operators could be separately compiled. BB, CC, and DD could be written first, then A 
written and compiled (bottom up), or the specification of A could be written and com- 
piled, then the specifications of BB, CC, and DD, and finally the implementation code 
for cach of the operators could be written (a combination of top down and bottom up). 

In the model shown in Figure 9 on page 31, the arrows represent data 
streams. Each of these is labeled with a lower case letter. The label is a naine for the 
data stream. PSDL data streams can carry two types of data values. The first type may 
considered the normal type. Normal type data can be any abstract data type. It is 
characterized by being immutable and no global representations are allowed. This [ca- 
ture prevents coupling problems within the prototype where operators communicate via 
shared data. State variables for an operator are specifically local to the operator and can 
only be changed internal to their own operator. This also prevents coupling problems 
in the prototype design. PSDL uses the immutable subset of built in Ada types, plus 
user defined types, and the special types TLMER and Sc aie sp 

The second tvpe of data which can be transmitted are tokens representing 
exception conditions. Tlus is the PSDL type EXCEPTION and corresponds to Mera 
exception construct. Thus, PSDL uses the Ada approach of representation hiding and 
data abstraction in program design. It is much simpler to use PSDL than to use Ada 
directly. For the translator, all variables, including user defined types, will be placed into 
an Ada package. The resulting Ada program will emplov the With/ use construct from 


Ada to make these variables available to the program. 
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b. Data Streams 

In PSDL, data streams represent a communication link between exactly two 
operators. One opcrator is the producer of the data while the other is tlre consumer of 
tae data. There are two tvpes of PSDL data streams. One is the DATA FLOW 
BRR EA DM the other is the SAMPLED STREAM. The DATA FLOW STREAM can 
be thought of as a first in first out (FIFO) queue capable of holding, at most, one data 
value. This data value may be used one time by the consumer operator. It may not be 
overwritten by the producer. In effect, this stream guarantees deliver of the data value, 
and guarantces that each individual data value will be read once and only once. The 
second type queue can also be thought of as a queue of length one. In this case, (the 
sampled stream), delivery of an individual data value is not guarantecd. The data value 
may be overwritten by the producer before the consumer reads it, or may be read mul- 
tiple times by the consumer, or not at all. The choice of data stream is dependent upon 
the control conditions specified for the operator. 

c. Operator Control Techniques 

Two types of control are allowed in PSDL. The first is periodic. This is a 
common form of operator control in which operators are fired by some regular schedule. 
This form of control is supported in PSDL by several constructs. The primary construct 
ERPERIOD followed by a time value. The SS in the ESS will recognize the PERIOD 
token and will utilize the time value supplied to gencrate an Ada scliedule program 
Which will invoke the Ada procedure representing the PSDL operator. The periodic 
operator must fire sometime between the beginning of the period and some deadline 
wich defaults to the end of the period [Ref. 19: p. 17]. Thus, PERIOD is an upper 
bound on the length of time allowed between any two firings of a given operator. This 
is an explicit period. 

It is possible to arrive at an implicit period. Such an implicit period would 
be known as an equivalent firing period. An operator for which an equivalent. firing 
period would be calculated by the SS would not contain the PERTOD token. It might 
inherit a period from a higher level of decomposition in a hierarchical prototype or it 
nught contain PSDL tokens for MAXIMUM EXECUTION TIME (MET), MAXI- 
MUM RESPONSE TIME (MRT), or MINIMUM CALLING PERIOD (MCP) which 
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would result in the SS calculating an equivalent firing period for the operator. MET is 
an upper bound on the length of time which may elapse from the beginning of execution 
of a module to the end of the execution of that module [Ref. 19: p. 205 METI 
applied to all operator types. 

MRT has two different interpretations. The first applies to periodic opera- 
tors. In this case, MRT is an upper bound on the time from the beginning of a period 
and the time when the last data has been output onto the output stream of the operator 
(Ref. 19: p. 20]. The second case for MRT applies to a class of operators known as 
Sporadic operators. Sporadic operators lack an exphcit PERIOD. Sporadic operators 
are triggered by the arrival of data on the input streams of an operator (or set of data 
streams for the NATURAL DATA FLOW (NDIY (Ref. 19: p. 20]. NDF is a form 
of control dependent on the flow of data through tlie prototype to cause the firing of 
operators. Tor the Sporadic operator, MRT is an upper bound on the clapsed time from 
the arrival of new data on the input streams to the operator and the time when the last 
data value is placed on the output stream of the operator in response to the arrival of 
the new data values. MCP is a lower bound on the elapsed time allowed between tlie 
arrival of one set of values on the input streams of an operator and the arrival of the 
next set of values on the input streams. For SPORADIC operators, if MRT is used, 
then MC must also pelusea Recibo o 

For sporadic operator control PERIOD is not specified. The SS calculates 
an equivalent firing period if the operators have the MET token. It uses the information 
calculated to generate a calling schedule for program oneration just as SS would if the 
program used the PERIOD token and were therefore periodically controlled. If the 
operator is sporadic and does not contain MET then the SS will conduct a topological 
sort of the operators to determine a calling schedule in Figure 16 on page 35 we see the 
application of tlie topological sort to a set of operators. The information required for 
the sort is found in the link construct of PSDL which is part of the GRAPII token. 
The acyclic digraph is generated from the link information. In the case of Figure 10 
on page 35 no MET information is supphed in the link construct. In Figure Ll on page 
36 MET information is supplied within the link construct. Tlie resulting schedule for 


each set of operators is the same: 
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link statement corresponding to 
above acyclic digraph - no MET are 
included for the operators 

a.l -> 2 

b.2 

c.3 


d.1 


possible schedule resulting from a topological sort 


T UTE 





Figure 10. Acyclic Digraph 


NDF control of sporadic operators 1s signified by tlie PSDL token TRIG- 
GERED BY. This token will be qualified by either the additional token ALL or SOME. 
TRIGGERED BY ALL indicates that an operator is to be fired when new data values 
have arrived on all the input streams to the operator. TRIGGERED BY SOME implies 
that the operator will be fired by the arrival of a new data value on any one of the input 
streams to the operator. Figure 12 on page 37 illustrates these two different con- 


structions. Note that the designer must specify which input streams the TRIGGERED 
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link statement for above AUGMENTED 
ACYCLIC DISRAPH - MET are include for 
each operator 


a.1:5 


possible schedule for abov e AUGMENTED ACYCLIC DIGRAPH 


1,2,3,4 





ee — 080 


Figure ll. Augmented Acyclic Digraph 


BY ALL/SOME construction refers to. He may specify a proper subset of the input 
streams in either case. [n this way, if an operator has multiple input streams, but only 
a few of them are critical to the firing of the operator, the designer may so specify. NDF 
is not normally combined with periodic control. The application of timing control to a 
model using NDF is allowed. The MRT and the MCP tokens may be used with the 


NDF form of control among SPORADIC operators. 
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triggered by all d,f,h 






triggered by some r 


k (no triggered by token) 
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Figure 12. “Triggered By” construction in PSDL 


Figure 13 on page 38 illustrates the combination of Sporadic and Periodic 
control. In this case, a conflict develops between the two schedules developed on the 
basis of: 

l. Topological sort 


2. Periodicity constraints 


S 


period = 10 


MET = 1 
period = 20 
3 MET «2 
period = 40 
MET =2 


C triggered by all a, b 


schedule resulting from periodic schedule 


HARMONIC BLOCK 
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schedule fails - A and 8 must fire before C due precedences 
established by the topological sort but periodicity constraints 
cannot be acheived 





(igure 13. Combination of Periodic and Sporadic Operators 


The SS would develop a schedule based on the periods specified. It would 
also develop a topological sort. It would compare the two schedules and would recog- 
nize that they do not match and mught fail. It would nevertheless allow the program to 
be compiled and run on the basis of the periodic schedule which would fail when C at- 
tempts to fire a second time before B has fired a second time. This indicates a flaw in 


the design of the prototype and would require the designer to intervene to correct the 


problem. 
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It is not the purpose of this paper to discuss in detail the development of 
senedules from the PSDL specification. The aim is to demonstrate that PSDL has a 
powerful set of language constructions to deal with real-time constraints in. software 
systems. PSDL offers a variety of means to control the operation of a real-time systems. 
It is necessary to discuss the forms of control available so that certain implementation 
aspects for the translator can be introduced. It is also important to recognize that Ada 
is not nearly so flexible in describing real-time constraints as is PSDL. 
Conditional firing of operators can be accomplished bv the addition of input 
Or output predicates in the PSDL specification. Referring to Figure 9 on page 31, the 
designer might specify one of the following: 
@ OPERATOR A TRIGGERED BY ALL a IF a:entical 
e OPERATOR CC TRIGGERED BY ALL b IF b: NORMAL AND d:eritical 


Thus illustrates the use of an input predicate. The triggering condition acts 
as a guard for the operator. The conditional can be applied to both Sporadic and Peri- 
odic operators. A Periodic operator would fire only if the input predicate were true. If 
it were not true, the Periodic operator would read the inputs without firing. The input 
conditional can depend only on the input values to the operator and any TIMER values. 


An example of an output control would be: 


ODBEBA TOS DD QUTPUT x Es 100 


This functions as if we had an explicit, conditionally executed filter operator 
following it [Ref. 19: p. 19]. The output guard provides a convenience to the designer 
but could be simulated by adding another operator to the prototype with an input con- 
dition on its firing. 

d. Timer 

TIMER is a PSDL construct which is useful in the developinent of real-time 
systems. À timer is an abstract state machine. In PSDL it is somewhat like a stopwatch. 
It has the primitive operations of START, STOP, RUN, and RESET. it is used for such 


things as measuring the length of time between two events, or the length of time the 
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svstem or an operator has remained in a particular state. TIMER does not function in 
the same way as a clock construct for an operating system. It does not provide direct 
control of operator firing, but can be used as a value for a PSDL input or output con- 
ditional to act as a guard to the firing of an operator. It is primarily provided to collect 
statistics about the prototype system. 
e. Exception 
It was noted above that PSDL supports both normal and EXCEPTION 
data types. The PSDL EXCEPTION is a built in type. It can be transnutted on any 
data stream as a data value. It can be suppressed by the use of input or output condi- 
tionals. It can be handled in PSDL or in Ada. Some possible operations for the PSDL 
EXCER MOM Jace 
o to create an exception with a given name 
o to detect if a value on a data stream 1s 
an exception with a given name 


normal (not an exception) [Ref. 19: p. 14] 


Although the PSDL exception is a data type and the Ada EXCEPTION is 
not, the Ada EXCEPTION can be used to implement and handle PSDL EXCEPTION 
types very conveniently. The major benefit from treating EXCEPTION as a data tvpe 
in PSDL is abstraction. Dy this abstract construction, a unified means of handling all 
exceptions throughout the prototyping process is created [Ref. 19: p. 14]. Since all ex- 
ceptions are handled the same way, there is no need for special constructions to handle 
each specific case. Thus construction of prototypes is simplified, and another step is 
taken toward automation of the prototyping process. This also simplifies translation of 
the exception condition into Ada. A generic exception handler can be created in Ada 
and instantiated by the translator as needed during translation. The abstraction eases 
the job of the prototype designer, which is the whole point of a computered aided pro- 


totvping system. 
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C. ADA AND PSDL 
l. Ada and Real-Time Systems Constraints 
a. Difficult Direct Implementation of Real-Time Constraints in Ada 

The Ada implementation of such aspects of real-time svstems as PERIOD, 
meet, MCP, MARI, and TIMER is not trivial. Ada DELAY by itself has no upper 
bound but is a lower bound on the delay implied. The Ada DELAY and SELECT 
constructs cannot be used to implement these performance constraints directly for a 
system of operators. The use of the type DURATION allows the approximation of an 
interval in a loop construct but it 1s not as flexible as needed. The use of TASKS in Ada 
provides more capability through the use of conditional entry calls. The problem with 
these constructs is that they require a good deal of efTort on the part of the programmer 
to implement, and the program is operating at the mercy of the Ada run-time system. 
The degree of effort required to implement these constructs directly in Ada is out of 
proportion with the aims of the rapid prototyping methodology. A more abstract and 
direct syntax is required to specify hard, real-time constraints which will make con- 
struction and demonstration of prototypes possible. If the designer 15 required to invest 
nearly as much effort into the creation of the prototype as the development of the sys- 
tem itself, there is no advantage to prototyping. Furthermore, the Ada run-time system 
wil not guarantee that the prototype design behaves in exactly the same manner as 
specified. The purpose of the SS and the DS in CAPS, is to ensure that the prototype 
functions within the real-time constraints applied to the design. Barring errors in design, 
the feasibility of such aspects of the system as control flow, order of firing of program 
modules, time behavior, and I/O formats can be demonstrated with CAPS. The ESS, 
frees the designer from the implementation effort required in Ada by automatically 
generating executable code in Ada, and by automatically generating control code in the 
form of Static and Dynamic schedules which enforce control and timing behavior. 
Therefore, PSDL supports develpopment of large and embedded Ada programs directly 


and easily. 
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b. Ada in Support of The CAPS Environment 
Ada is most suitable for the development of CAPS for several reasons: 


ə Ada is the language mandated for development of embedded and real-time systems 


Ion Oe 
e Ada provides constructs which can be used to implement more abstract unung be- 
havior. 


e Ada constructs can be used in a multiprocessor environment 
* Ada provides simple exception handling facilities 
9 the GENERIC feature in Ada provides a simple means to implement automated 
prototvpe construction 
2. Implementation of The PSDL Model in Ada 
At this point several design implementation aspects of the Translator (TL) por- 
tion of ESS will be presented. 
a. Operator 
The OPERATOR construction of PSDL can be impleinented by producing 
an Ada procedurc. This procedure would contain code to iniplement any PSDL input 
or output conditional statements. It would also contain code to check the validity and 
availability of data for NDF control. Before presenting an example of this construction 
it will be necessarv to develop the implementation of the PSDL data streams. 
b. Data Streams 
A PSDL data stream may be thought of as a simple queue of length one. 
Appendix C, part A, illustrates the construction of a simple queue in Ada. It 1s a pro- 
cedure. With some minor modification, the queue can be made generic. This 1s ac- 
complished by enclosing the procedure in a package and adding the Ada GENERIC 
part. An Ada private type is declared in the generic part. This private type allows the 
passing of any data type into the queue simply by declaring the type description at the 
point of generic instantiation. Thus, a generic queue is created which can be used at any 
point where a data stream is needed, bv the simple use of the Ada generic instantiation. 
This technique is illustrated in Appendix C, part A. 
(1) Generic Buffer Task. Recall that there are two different type data 
streams 1n the PSDL schema. One is a FIFO queue while the other is the sampled 


stream. Therefore, two different generic queue models are required. One of these 
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receives and transmits data without condition. This is the sampled stream, and will be 
referred to as a simple queue. Each data value in the simple queue may either be read 
many times or not at all. The second queue model will have a Boolean flag indicating 
whether or not it has been written since the last read operation or whether 1t has been 
read since the last write operation. This is the FIFO queue used for NDF control. The 
Boolean flag is necessary since delivery at least once, but only once, of each data value 
sent through the queue is required in natural data flow. If there is a violation of the 
PIFO rule, then the Boolean flag will result in the queue raising an exception. There 
are two possible exceptions. One will be identified as Underflow, and the other as 
Overflow. Underflow will be raised if the consumer operator attempts to read the queue 
before it has been updated by the producer operator. Overflow will be raised when the 
producer attempts to write to the queue before the consumer has read the previcus data 
value, 

The translator must have some basis to select the appropriate queue 
for a given data stream. If an operator contains the TRIGGERED BY ALL tokens then 
FIFO queues will be selected for the streams listed following the ALL token. If the 
operator contains the TRIGGERED BY SOME tokens then simple queues will be se- 
lected for the data streams. A third condition is if the operator contains no TRIG- 
MED BY tokens. In this case simple queucs will be selected. [or example. in 
Figure 12 on page 37, operator T has four input streams. The specification for T is, 
TRIGGERED BY ALU d,fjh. The translator will select FIFO queues for streams d,f, and 
h. Stream g will be a simple queue. In the same figure, operator P has four input 
streams. The specification for P is, TRIGGERED BY SOME r. In this case all data 
streams will be simple. Again in Figure 12 on page 37, operator FF has two input 
streams. The specification for FF lacks à TRIGGERED BY token. Therefore, all the 
streams are simple streams. Thus, 1f the operator specification lacks the TRIGGERED 
BY token, or contains the SOME token, the streams will be simple. Ifa stream ts not 
listed in the ALL specification it will be simple. Only when the operator contains the 
ALL token will à FIFO queue be selected. Note that 1t 1s the triggering conditions for 
the consumer operator that determine the type data stream(s} that exist between any two 


operators. 
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Thus far, the data streams are modeled as a generic package con- 
taining a queue procedure in Ada. This construction is not sufficient. The SS and DS 
have generated a schedule for the time critical operators and this schedule 1s enforced to 
ensure real-time constraints are met. Some operators do not have time critical con- 
straints. These operators are called into the empty or excess time in the worst case 
schedule for the time critical operators. It is possible that a time critical operator is the 
consumer of data from a non-time critical operator. The time critical operator has pri- 
ority and is scheduled to run by the SS on some repetitive cycle. The non-time critical 
operator is fired, as convenient for the DS, in the excess time in the main schedule. 
Suppose a non-tme critical operator is called and is attempting to write to the data 
stream, when it 1s interrupted bv the DS in order to run a tine critical operator. A'so 
suppose that the time critical operator is the consumer for the data from the non-time 
critical operator. When the consumer attempts to read the queue, tbe results will be 
uncertain. 

This difficulty can be overcorne by making the generic queue into an 
Ada task. This task will be called a buffer task. The task is then enclosed as a generic 
package which can be generically instantiated as before. The difference is that the pro- 
ducer and consumer operators will use entry calls to write to or read from the buffer. 
In this way, once the buffer task is called, whatever operation is taking place on the 
buffer must be allowed to complete before an interrupt can take place. The operation 
tume for any buffer task should be very short, so there should be little tme penalty to 
the scheduled operation of the program. On the other hand, buffer operation is pro- 
tected from interruption and the operators are unükely to get uncertain results from 
reading them. Appendix C, part B, contains a listing for the Ada code to implement the 
two types of butler tasks, SAMPLED STREAM and FILO. 

(2) Buffer Task Selection. How does a data driven operator know that 
the data stream (buffer) has new data, and that it should therefore fire? The buffer al- 
readv contains a Boolean flag to indicate that it has been updated (either written to or 
read from). However, now that tt is a task, an entry call must be made to accessithe 
Boolean flag. After finding the state of the flag, the consumer operator would then need 


to execute a task entry to access the actual data in the buffer. Tlis would be 


inconvenient. A simpler method would be to apply a similar Boolean flag to each pro- 
ducer operator of a NDF data stream. This would be an Ada in/out parameter to the 
producer procedure. The consumer procedure would incorporate a conditional guard to 
test the state of the Boolean in/out parameter of the producer. If the condition of the 
flag indicated that the producer has executed a write operation to the buffer since last 
read, the consumer would reset the variable to the state indicating that the data has not 
been updated and would then execute an entrv call to the buffer(s) in order to fire itself. 

(3) Buffer Length Selection. It may be asked why a buffer length of size 
one has been chosen to implement all buffers. The choice of buffer length is arbitrary 
in any case. Figure 13 on page 38 illustrates the source of the problem. Suppose a de- 
signer builds a system which contains both periodicity constraints and data flow control 
as in the figure. As previously discussed, the SS will generate a schedule based on 
periodicity and will also conduct a topological sort for control based on NDF. If the 
two schedules happen to match then the system will operate. If they do not, then the 
system 1s likely to fail. The SS will still allow the coinpilation and operation of the 
program based on the periodicity constraints. This will allow the designer to see the 
failure and decide on necessary changes and design alterations to make the program 
work. Figure 13 on page 38 shows the failure of the program will occur on the second 
time C attempts to fire. In this case buffer length has no effect on the operation or 
failure of the program. However, it is possible that a combination of various buffer 
lengths, periodicity constraints, and NDF constraints might operate correctly for some 
length of time before failing. 

Figure 14 on page 46 shows a case where operation of the buffer ts 
uncertain in the presence of both periodicity and NDF constraints. In this case, the fact 
that we have chosen a buffer of length one ensures that very little runtime will be re- 
quired to reveal the instability of this design. Since one objective of the CAPS archi- 
tecture is to save development time, it 1s important to reveal errors in design quickly in 
testing. Dy selecting buffers of length one throughout tlie prototvpe, we ensure that 
flawed designs, sucli as the one i1 Figure 13 on page 38 and Figure 14 on page 46 are 
revealed after a very short amount of run time. In general, a flawed design will fail 


eventually no matter what length buffer 1s cliosen. Since the buffer length is an arbitrary 
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period = 15 period = 20 


calling schedule for C 


0 20 40 60 





calling schedule for 8 


AAA M 


0 15 30 45 60 


B writes b at 15 - C reads b at 20 
B writes b at 30 - C reads b at 40 


B writes b at 45 - 


now B attempts to write b at 60 - 
and C attempts to read b at 60 - 
success or failure of this operation Is 
uncertain - faiiure Is iikely and the 
design is poor 





Figure I4. Uncertain buffer operation 


choice, it is better in the CAPS to ensure rapid failure of poor designs. A buffer length 
of one will ensure this selection. 

(4) Buffer Selection Conflicts. Another problem which arises in buffer 
selection is illustrated in Figure 9 on page 31. In this case we have the decomposition 
of an operator into three lower level operators. The designer will enter a specification 
for both the top level operator Á and for the lower level operators BB, CC, and DD. 
Suppose operator A includes the tokens TRIGGERED BY ALL a. Also suppose that 
operator BB does not contain the TRIGGERED BY ALL tokens. When the TL selects 
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a buffer task for A, it will instantiate a FIFO buffer task to implement a. For BB, it 
would select a sampled stream task to implement a’. Although, a and a’ carry the same 
data, and they have not been implemented with the same type buffer. The TL does not 
check inheritance rules. In operation data would be placed onto a and would then be 
passed to a’ and into BB. The results of this translation will be uncertain. It may 
present no difficulty or may behave erratically. The user must prevent this type error 
by ensuring that operators wluch result frorn the decomposition of higher level operators 
have the same triggering conditions at the input in order to prevent the buffer nusmatch 
just demonstrated. This difficulty only arises for lower level buffers which mirror the : 
input buffers of the highest level operator of which they are a part. This is true because 
the type bufler required at any point in the system is determined by the triggering con- 
ditions of a consumer operator. Therefore, decomposition rules do not affect the spec- 
ification requirements of operators CC and DD in Figure 9 on page 31. However, if A 
is TRIGGERED BY ALL a, then BB must be TRIGGERED BY ALL a’. It is a rule 
which the designer must enforce at this point. A utlity similar to the C language lint, 
could be developed to check for this type inconsistency and incorporated into the ESS 
as an automatic part of the prototype translation, compilation, and export facility. 

(5) The State Buffer. A final difficulty in data stream implementation 1s 
that of PSDL state variables, designated by the token STATES INITIALLY. Each state 
variable will have its own buffer task. An example is seen in Figure 9 on page 31. 
Operator CC is a state machine. It has a state variable which is transmitted along buffer 
task d. The value of the data type traveling along d must have some initial value. That 
wuusus found m the STATES INITIALLY statement in PSDL. To insure the correct 
initial value for the state variables in the program, bufler task d must be loaded with the 
correct value prior running the prototype. An Ada procedure called PRELOAD will be 
produced by the TL for all PSDL prototypes. It will contain a series of statements to 
put the correct initial values into the appropriate buller tasks. If there are no state 
variables in the program, the procedure will simplv be empty. The SS will always call 
PRELOAD before the execution of anv schedule it creates for the prototype. The pre- 


loading procedure will not be part of the schedule proper. 
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It will run one time only to initialize the state buffers and will not be run again unless 
the prototvpe program is restarted from the beginning. 
c. User Declared Data Abstractions 

Already mentioned is the fact that all user declared types will be placed in 
an Ada package which will be used throughout the program. The listing for such a 
package is found in Appendix B, part C. This method allows the use of private types in 
the generic buffer task. At instantiation, the particular type variable to be sent through 
the buffer is declared. The actual description of the type is in the variable package. This 
package requires only an Ada specification part since it does not implement anvthing 
itself. In addition to user declared types, all other variables which would appear in the 
specification part of the Ada implementation will be placed in this same package. This 
technique is a useful Ada design tactic. It is especially useful in programs where ranges, 
intervals, delta values, or constants need to be assigned to variables, types, or subtypes. 
It insures that when variables need to be changed tn a program, they can be found 
quickly and changed. There is no need to worry that a particular instance of the variable 
was overlooked somewhere in the program. In real-time systems such assignments of 
ranges, delta values, and constants mav be seen to be quite common. For example, in 
an engineering plant control system, fixed point numbers might be emploved to describe 
temperature measurements. These would have a particular delta value, perhaps .1 de- 
gree Centigrade. The accuracy required might result from engineering considerations 
such as available sensor accuracy or the criticality of the system. If the program were 
written to accept data from a sensor of .1 degree centigrade and a sensor was needed and 
eventually developed which was accurate to .01 degree centigrade, the program would 
have to be modified to reflect the new delta value of .01. If the package technique had 
been used in program development, the effort required for the change would be minimal. 
A single point in the program would be adjusted and the modification would be coin- 
plete. Lacking the package technique, the entire program listing would have to be ex- 
amined to ensure a correct change. CAPS is thus developing Ada code which is easily 


maintained and modified. 
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d. Timer 
Toe TIVER module must be implemented. The purpose of TEMER is to 
measure elapsed time between two events, the length of time an operator has been in a 
particular state, or to act as a conditional guard for operator firing. The four primitive 
@eerations for the timer are START, STOP, RESET, and READ. It will use the Ada 
standard package CALENDAR to access the system clock. The timer will have a 
Boolean run switch. 
At START, the Boolean run switch will be set to true, the system clock read 
and the value of the reading stored as the initial starting point. At some time later a 
READ 1s performed. The system clock will be read and the value of the initial reading 
subtracted froin it to calculate the elapsed time. Thie initial value will not be changed. 
Actual clock time is not output. Elapsed time is output. At STOP, the system clock 1s 
read and the value stored in a simple array. The initial actual clock time is not output. 
Elapsed time is output. At STOP, the system clock is read and the initial reading 1s 
subtracted from the reading at STOP and the value output as the TIMER value. The 
reading thus obtained is stored as the grand total time elapsed. At a subsequent 
START, the system clock will be read and written over the old value. The grand total 
will not be disturbed. At another STOP, the new elapsed time will be added to the grand 
total and the will be output as the elapsed time. The RESET operation will stop the 
timer and return all timer values to the zero state. TIMER will be an Ada generic 
package. It can be instantiated wherever needed in the prototvpe verv easily. An ex- 
ample of an Ada package to implement TIMER is found in Appendix C, part C. 
3. Advantages of The Ada Implementation of PSDL Constructs 
Ihe CAPS utilizes the relatively simple PSDL design and specification language 
to describe prototypes. It creates Ada source code for an operational prototype which 
can be compiled and run tested. It utilizes an automated translation facilitv to produce 
this code. It takes advantage of the powerful generic construct in Ada to simplify 
translation. The resulting code uses packaging of data types to sunplify translation and 
program maintenance. Use of private types supports representation luding. Smce PSDL 
data types are immutable, it is necessary to utilize a strictly typed language to implement 


them. Otherwise the protection against unpredictable side effecting afforded by the 
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unmutable PSDL data types might be lost in translation. Ada provides the strong type 
checking required. A similar observation can be made regarding the PSDL prohibition 
against global variables. CAPS combines the powerful features of Ada and PSDL to 


provide an effective tool to support the rapid prototyping methodology. 


D. TRANSLATOR DESIGN AND CONSTRUCTION 
l. The KODIYAXK System 

A few words should be said regarding the design and construction of the trans- 
lator itself. The translator 1s created using an automated translator generator called 
KODIYAK. KODIYAK was developed by Robert Herndon at the University of 
Minnesota as a doctoral dissertation. [Ref. 24] It is available as a research tool and is 
quite effective. The system is based on Knuth's work in attribute grammars. [t utilizes 
a version of Jalili's algorithm to evaluate the semantic tree it creates when generating the 
translator. The tool incorporates a file called K as a pre-processor to the LEX 
[Ref. 27] and Yacc [Ref. 28] tools in the UNIX operating system. 

Ihe process of translator production and usage is illustrated in Figure 15 on 
page 51. To produce a translator with KODIYAK, the user must create a source file. 
This file contains a listing of the terminal and non-terminal tokens of the source lan- 
guage to be translated. It also contains a listing of the valid attributes which each token 
may take on, as well as any precedence relationships which may be required to properly 
evaluate ambiguous cases in the grammar. Finally, the file contains a listing of attribute 
equations. These equations describe the relationship betwcen the source language (in 
this case PSDL) and the target language (in this case Ada). The translator generator 
system, KODIYAK, utilizes these equations to produce a translator in executable C 
code. The translator thus created 1s an executable program. Dy running this prograin 
with a text file in the source language as input, an output file is created which contains 
the equivalent code in the target language. A complete listing of the translator gencrator 


source file for the PSDL to Ada translator is found in Appendix D. 
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Figure 15. Translator construction and usage 
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IV. GENERAL APPLICABILITY TO TELECOMMUNICATIONS 
SOFTWARE SYSTEMS 


What is the relationship of this research to Naval telecommunications systems and 
software? Current DOD policy indicates that software for embedded computing systems 
will be written in Ada or converted to Ada, although the application of this policy is left 
to the individual services [Ref. 29 p. 71-72; Ref. 30]. Embedded systems are those 
computers which form an integral part of a larger system, such as a communications 
switching processor, a missile guidance system, or a manufacturing process control 
computer [Ref. 12 p. 3]. Naval telecommunications systems are embedded systems and 
therefore are subject to this policy. No current Naval teleconimunication system 1s 
written in Ada. Naval Data Automation Command (NAVDAC) has expressed an in- 
terest in the development of software tools and techniques to improve productivity in the 
maintenance and production of Navy software systems [Ref. 31]. This thesis addresses 
the creation of a software tool designed to improve the productivity level and efficiency 
with which Ada software can be produced. It also demonstrates, coincidentally, the 
application of several existing software engineering tools and techniques which can be 
used to address the conversion to Ada or the development of software components for 


future systems. 


A. SOME CURRENT NAVAL TELECOMMUNICATIONS SYSTEMS 

Table 1 on page 53 (Ref. 32] summarizes some information regarding several cur- 
rent Navy telecommunications systems. These are the Common User Digital Informa- 
tron Exchange System (CUDIXS) and the Naval Modular Automated Conmunications 
System (NAVMACS). The annual maintenance cost figure cited is for the software 
system in each case. No hardware maintenance costs are included. The maintenance 
costs for NAVMACS V5 and V5a is unknown as the systems are still undergoing de- 
velopment. Not listed in the table, is the development costs for the systems. Numerous 
government and private laboratories and corporations participated in the development 


of these svstems over an extended period so that the development costs are not easily 


Table 1. A SUMMARY OF SOME CHARACTERISTICS OF CURRENT NAVY 
TELECONIMUNICATIONS SYSTEMS AND THEIR SOFIWARE 













NAVMACS Family 


CUDIXS VI V2 V3 VS/Sa 
Annual Maintenance Cost | $500K S200K . $250K $500K unknown 
IOC 975 SOV 79T APR 50 DEC76 (1) 
Required Memory _ 64K 64K 64K 128K (2) 
Code Size (Lines) 120K 49K 54K 90K (3) 
Language ULTRA-16, the 16 bit assembler code for the 
AN/UYK-20 computer which is the basic hardware unit 
for these systems 
Operating System none none none MOS (4) (5) 
Constraints CUDIXS must maintain precise timing to properly 








(1) 


(2) 


operate within the receive; transmit windows required 
by link protocols. NAVMACS family, due to heavy 
loading of the system, concentrates on efficient use of 
svstem resources such as central processor unit and I/O 
capacity. 


NAVMACS V5 is being developed in two phases IOC for Phase A was JUL 83. 
IOC for Phase B was JUL 86. IOC for V5a is expected to be OCT 88. 






ge 


NAVMACS V5 is a three computer system. Main computer memory 1s 256K. 
It can operate in degraded mode in 192K. The remaining computers require 
64K. One will normally have 256K for fallback purposes. 


Code size by lines does not accuratelv reflect the presence of comments and the 
extensive use of macro instruction statements. Current size 1s 309,000 (decimal) 
16-bit words. 


MOS = Modular Operating System 


NAVMACS Operating System (IOC). This 1s a higlily modified and enhanced 
version of the MOS used in the V3. 


> e e e T ate A t l 
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determined. An examination of the initial operational capability (LOC) dates for the 
systems makes it clear that Ada was not a feasible choice for the development of the 
software for these systems, since Ada was not standardized until 1983 [Ref. 33]. [t is 
also clear that there are hardware limitations on the size of code which can be tolerated, 
due to the small memory capacities available in the AN/UYK-20 computer which is the 
central processor for all the systems listed. Note that the code 1s very large in terms of 
number of instructions (or line count) albeit very compact, owing to the use of assem- 
bler language. NAVMACS V5 and V5a use up to three AN/UYK-20 computers, while 
CUDIXS and NAVMACS VI, V2, and V3 are single processor units. The various 
versions of the NAVMACS family differ in the variety and quantity of capabilities and 
services provided to users by the system. The VI and V2 are tvpically found on frigate 
and destroyer size ships, while the V3 1s reserved for cruisers, large amphibious ships, 
large supply ships, and flag configured ships. NAVMACS V5 is found only on carriers 
and large command and control ships. 

The software for all systems is written 1n assembler language (ULTRA-16, the as- 
sembler language native to the AN/UYK-20 computer). As many common elements of 
the developed assembler code as possible have been used among all the systems 
[Ref. 32 encl. 3]. The software for the VS has also been developed to operate on the 
AN/UYK-44 computer [Ref. 32: encl. 3]. 


B. SOME PROPOSED NAVMACS FOLLOW ON SYSTEMS 

There is currently no formally accepted follow on to these systems. Initiatives to 
enhance and improve NAVMACS exist. Two approaches to proposals for follow on to 
NAVMACS will be briefly presented which will serve to illustrate possible applications 
for CAPS. Some possible opportunities for the application of tools and tecliniques on 
which CAPS is built will also be suggested. 

l. NAVMIACS iViodel II 

There is an idea for a follow on system called NAVMACS Model IT (afterward 

referred to as Model I1) [Re£. 34]. Table 2 on page 56 is a listing of typical services 
found in current NAVMACS systems and the proposed additional services for 


NAVMACS Model II [Ref. 34: pp. 15-16]. The Model II proposal envisions a single 
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tvpe of computer and software package which could be used in many different applica- 
tions by changing the peripheral suites attached to the central processor 
(Ref. 34: pp. 28-34]. The Model II envisions the use of some “smart” peripherals. 
These would include: 
o Programmable Front End processors to interface: 

l. circuit cryptos 

2. system computers 

3. offline storage devices 

4. operator interface devices 


* remote terminals for message preparation and distribution [Ref. 34: pp. 17-22] 


The Model II would use data display units at operator terminals vice control 
teletvpes. This would speed message entry, screening, and distribution. The terminal 
would provide some means to ensure correct forinat and entry of information during 
message preparation [Ref. 34: p. 12]. This might take the forrn of message templates 
or canned message formats. Remote terminals in non-mission critical areas might use 
non-development items (NDI) [Ref. 34 p. 21]. “NDI is usually off-the-shelf or 
commercial-type products, but may also include equipment already developed by or for 
the Department of the Navy, or other military services or foreign mulitary services 
[Ref. 35]..” [OC for a follow on system might be the mid 1990s [Ref. 32 ]. 

2. Unified Network Technology 

Unified Network Technology (UNT) and Communication Support System 
(CSS) are current initiatives to improve and advance the state of the art in Naval com- 
munications systems. UNT anticipates the creation of communication packet networks 
which will have flexible topologv. These networks would provide most eflicient use of 
existing and future communications systems by allowing routing of communications 
through any available communication media in an automated packet network. Present 
svstems involve the use of dedicated links and dedicated hardware svstems. This cau 
result in inefficient use of communications resources as some media remain idle while 
other media is heavily loaded. UNT would use automated means to select the available 
media and use it transmit communications traffic. The CSS comprises the shipboard or 


shorebased network controllers and interface units to establish connectivity. between 
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Table 2. TYPICAL FUNCTIONS FOR NAVMACS ANDO PROPOSED 


NAVMACSMODEL II 


Current Function DescripHiom omn Vi V2 V3 V4 VS 
Up to Y Fleet Broadcast CAMA Xe X X quae 
Lp to 4. Full Period, Permunia tiene me sere ere XX E 
INS Subscriber Capability mm X "x xe ms 
Flexible Circuit De TT x E 
System Control by Displays — eee X WES 
On-line Message Compro re eee X =- 
Long Term Msg Storage Retrieval ee Xx ed 
Data Base Storage; Retrieval oem Ue E m 
Remote Terminal Ses snttsSãá: a 
Data Base For Onboard Organizatii m an n me x Ww 
Automatic OnboardaDelivenvi c E ME X. nd 
Duplicate Message Processing d me MEM X CA 
Automatic Circuit Selecionar ME X X 
Additional! Nfodel II Functions .... A e A ES 
Tactical CUDIXS (Ship-Ship OTO' de TNR EIU X x CES 
Add System Control by DispED E aa AS x 
On-line Composition With Formats RAP ML 
Flexible Circuit Definitions oT EU 
(including CUDIXS broadcast, LAB, NATO circuits 
fleet broadcast, FPT, automated nets) 
Ikemote Site5:: icu I A A Pe: 
Add More Remotea MES oseere aere e xd 
Flexible Configuration of Remote Sitestand Cireúits x 
Increased On mee Es X. X ES 
Automated HT NeT CAI = A entree X X a 
Automated HE Net Controls e — 
Semi-Automatic Distribütiolyss-..--—— 1 NE E 
Improved Long Term Message Storage and Retrieval x UNES 
Improved Duplicate Search aae a eee eee » 
CannedwVIesswee Composiuonc-- terre etn ee a 
Decrease Vise Transmission Delans eee x 


users by employing the various hardware resources available. These systems approaches 


to communications will be software intensive. Distributed network control, flexibie 


network topology, 


and adaption to changing communications loads will require soft- 


ware control. CAPS could be utilized in the developinent of such software. 
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C. POSSIBLE CONTRIBUTIONS TO TELECOMMUNICATIONS FROM CAPS 

RESEARCH 

Current budgetary uncertainties, changing threat and mission requirements, 
changing technology, and long developmental lead times will certainly impact any future 
systems. As uncertainty is inherent in anv discussion of future technology applications, 
it is only possible to suggest several possible research avenues arising from CAPS re- 
search, which might be applied to telecommunications software systems problems. 

l. Rapid Prototyping and CAPS 

It is likely that future systems will seek to provide more and faster service to 
users by automating many more functions. Automated functions implies the use of 
computing svstems and software. Software requires development and the first step in 
software development is definition of the functional specifications. Rapid prototyping 
methodology directly addresses the early, precise definition of functional specifications 
so that full scale development of the system can proceed. CAPS offers a tool to imple- 
ment Ada program prototvping and design in a rapid prototvping environment. Once 
fully implemented CAPS can be applied directly to the development of new telecommu- 
nications software systems. 

New guidance under Secretary of the Navy Instruction 5200.37 [Ref. 36] de- 
fines acquisition policy for software intensive command and control information sys- 
tems. This policy applies to those research and development programs in which software 
cost represent a substantial fraction of the total system development costs (more than 
60 percent) [Ref. 36]. Specifically addressed are the use of software prototypes to sim- 
ulate important interfaces and to perform the main functions of an intended system 
without strict adherence to the final standards in hardware, speed, size, or cost con- 
wans required of the finished system [Ref. 36]. The CAPS system as currently 
planned will provide system simulations of precisely that type. The CAPS svstem, 
however, aims to provide simulations which do conform closely to any real-time con- 
straints required of the proposed software system. Furthermore, CAPS implements the 
rapid prototyping paradigm, offering demonstrations for the customer. This meets the 
requirement to promote ". . . effective interaction between the user and the developer 


(Ref. 36].” The policy to promote early delivery of command and control information 
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svstems software products through rapid prototyping can be met through the applica- 
tion of CAPS, CAPS could also meet the need to reuse as much existing software as 
possible, and the prototvpes produced will be written in a high order language (Ada) 
[Ref. 36]. 
2. Reuseable Assembler Code 

A generally available feature in Ada compilers is the ability to import assembler 
code to implement sub-program bodies where specd of execution, or compactness of 
code is a concern. CAPS will use retrieval of reuseable software modules to speed pro- 
totyping. These reuseable modules are expected to be Ada code, but could be sections 
of assembler code where necessary. So long as Ada compilers are available for the target 
machine, the assembler code already written for that machine 7o1:'’d be reused. There- 
fore, the question of conversion to Ada ts not only, “Should the systems be converted 
to Ada?; “but also, “How much of the existing code needs to be replaced?" Functional 
specifications for existing systems are understood (presumablv) empirically since the 
systems exist and are operational. Given the functional specifications, they could be 
expressed conveniently in PSDL and input into CAPS to generate an Ada prototype, 
which could be proofed, then finished out using Ada or assembler to implement the Ada 
subprograms. Several additional questions also arise including: 

e Can the assembler code be appropriately decomposed into modules? 


e Can the assembler code modules be described by normalized specifications within 
the software base? 


e Can the functions of the assembler code be decomposed so that part of the system 
can be implemented in Ada and the current code reused? 


* Does there exist an Ada compiler for the AN/UYK-44 computer and for that 
matter, what will be the next generation communications computer? 


e What costs are associated with such an approach as opposed to implemenüng the 
svstem entirely in Ada? 
3. Subordinate Tools And Techniques 
a. Translators 
Subordinate to the overall CAPS is the technique of developing and utilizing 
automated translator generators to produce automated translators. In principle, this 


approach could be applied to the conversion of existing programs in any language into 


any desired implementation language. Thus it may be possible to translate curient as- 
sembler code software directly into Ada. It would be necessary to examine the 1ssues 
of cost and feasibility of such an approach. It would also be neccesary to empirically 
demonstrate the concept and to produce a formal definition of the relationship between 
the two languages to ensure correctness in the final product. 
b. Editor Generators 

The Model II envisions the use of templates or preformatted message 
blanks for preparation of messages for transmission on electronic terminals. Thus facility 
currently exists in some installations of NAVMACS and CUDIXS. In CAPS, a similar 
capability is envisioned. It takes the form of a syntax directed editor for PSDL. This 
editor would understand the correct syntax and usage for PSDL and would assist the 
Operator to enter a syntactically correct PSDL prototype into the system. There exist 
several automated application generator facilities to create such “smart” cditors 
[Ref. 17: pp. 12-14]. The approach in CAPS will be to utilize such a generator to create 
the syntax directed editor for CAPS. It may well be feasible to apply such an editor 
generator to generate editor facilities which “understand” the correct format for various 
types of Naval messages. Generation of custom editors for general message or struc- 
tured messages (JINTACS, et.al.) might be possible. These techniques are incidental 
to the central thrust of CAPS and this thesis, which is to create an integrated system of 
tools for the generation of Ada applications. 

c. Network Simulations 

CAPS models software systems as systems of operators communicating via 
data streams. Each data stream in the CAPS could be a FIFO queue or a sampled 
stream. Each operator may have time constraints and conditional input or output. 
Thus, a CAPS model closely resembles a petri net, a system of nodes connected by 
communication paths. In principle, the basic elements of CAPS could be utilized to 
model and study the behaviour of networks. The data streams which now have queue 
length one, could be easilv modified to provide generic queues with length n. Thus it 
mav well be possible to use CAPS as a tool to model various network architectures, to 
provide operations research simulations of any network problem. Statistics collected 


from the run time profiler could provide insight into questions of network stability, 
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throughput, and possible choke points. The graphic user interface would provide a 
pictoral representation of the network. The syntax directed editor and the software base 


management system would simplify construction of network models. 
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V. CONCLUSIONS AND FUTURE RESEARCH POSSIBILITIES rOR 
CAPS 


It is feasible to describe a prototvpe in PSDL and to use an automated facility to 
translate the prototvpe into Ada. The present translator lays a sound foundation for 
further development. It implements and recognizes the full syntax of PSDL as published 
by Luqi in her Ph.D. dissertation [Ref. 19]. The fundamental conceptual design unple- 
mentation of the major PSDL syntactical constructs has been completed and docu- 
mented. The translator produces rudimentary Ada code for interconnection of reuseable 
software program modules. Several additional rescarch possibilities exist. First, the 
current translator is an empirical demonstration of the capability. Therefore, it should 
not be expected to function properly in all cases. Work must be undertaken to establish 
a rigorous, formal definition of the relationship between the syntax/semantics of PSDL 
and the syntax/semantics of Ada. Once such a rigorous definition has been produced, 
it must be applied to the translator to produce a facility which works for general cases. 

Second, Ada is a robust language with a large syntax. PSDL is also a robust lan- 
guage, but has a very small syntax. Can PSDL effectively describe all (or most) of the 
constructions possible with Ada? This 1s similar to the formal definition problem. It 
may be necessary to define certain PSDL constructions and specify the Ada construction 
used to implement it in much the same way as Timer, Operator, and Data Stream have 
been specified in this thesis. It may also be necessary to specify that certain Ada con- 
structs cannot be adequately represented in PSDL. Thus is unlikely; however, imple- 
mentation of some Ada constructs may require highly sophisticated versions of the 
translator. 

Third is the issue of code optimization. Some programs may require optimization 
for speed of execution, while others require optimization for code size. Can the trans- 
lator be made to generate Ada implementations based on optimization criteria? 

Fourth, the Static Scheduler (SS) uses a pre-processor written in Kodivak to extract 


inforimation about real-time constraints for various operators. This information is used 
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to generate the static schedule for program operation. Kodivak provides the facility to 
define separate sets of lexical definitions and attribute equations which apply in specified 
cases. Thus the pre-processor should be integrated into tlie Translator. This would 
eliminate the pre-processor as a single entity in the Execution Support System and sim- 
plify the integration of the Translator, Static Scheduler, and Dynamic Scheduler. 
Finally, the Translator, Static Scheduler, and Dynamic Scheduler must be integrated 


into a single tool, the Execution Support System, which can be integrated into CAPS. 
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APPENDIX A. PSDL GRAMMAR SUMMARY 


Several conventions are used for symbology in the grammar. [ Square Braces ] in- 
dicate optional items. ( Curly Braces ) indicate items which may appear zero or more 
times. Bold face type indicates a named terminal symbol which must appear in the 
program listing the programmer writes. “Double quotes” indicate character literals 
which must appear in the program listing. The "|^ vertical bar indicates an exclusive-or 
selection. In this case the programmer selects one and only one of the items separated 
by the vertical bar. 

As an example, the token timing_info is one of six mutually exclusive possibilities 
which mav define the attribute token. The attribute token may appear zero or more 
times to define the interface token, which is a required attribute of the operator spec 
token. Timing info, if selected for attribute, may be empty, or it may contain one or 
more of the optional tokens allowed to define timing info. Each of these tokens may 


appear no more than one time for a given instance of timing info. 


psdl = ( component | 


component = | data tvpe 
| operator 


data type = type id tvpe spec type impl 

operator = operator id operator spec operator impl 

type spec — specification [type decl] (op spec listj. [functionality] end 
op spec list — operator id operator spec 


operator spec = specification interface [functionality] end 


interface = {attribute [reqmts_tracc]} 


attribute = | generic param 
| input 
| output 
| states 
| exceptions 
| timing info 
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generic param = generic tvpe decl 

Input = input tvpe decl 

output — output tvpe decl 

states — states type decl initially expression list 
exceptions = exception 1d list 

id_list = id { 10 


tuming info = [maximum execution time time] 
[minimum calling period time] 
[inaximum response time time] 


time = number [unit] 





unit = | microsec | ms | sec | min | hours 


reqmits trace = hy requirements id list 


functionality = [keywords] [informal desc) [formal desc] 
keywords = keywords 1d list 

informal desc = description "(^ text “)” 

formal desc = axioms "(" text “3” 


tvpe impl = | implementation Ada id 
| implementation tvpe name ( op impl list ) end 


op impl list — operator id operator impl 


operator impl = | implementation Ada id 
| implementation psdl impl 
psdl impl = data flow diagram 
[streams] 
[timers] 


[control_constraints] 
[informal desc] 
end 


data flow diagram = graph ( link j 
link = id ”.” opid "--" id 

opid = id [ ^^ time] 

streams = data stream type decl 


pP os 


tvpe declw—erd list ^: type name I IGNI type name, 


tvpe name = [id 
| id ale type_decl “Y 


timers = timer id list 


control_constraints = control constraints { constraint } 
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constraint = operator id 
[triggered [trigger] [ “if predicate] [reqmts trace] | 
[period time [reqmts trace] | 
[finish within time [reqmts trace] | 
(output id list if predicate [reqmts. trace] ) 
(exception id [if predicate] [reqmts_ trace] } 
ftimer op id [if predicate] [reqmts trace] ) 


timer op = | start | stop | read | reset 


trigger = | byallid list 
| by some id list 


predicate — | not predicate 
| predicate and predicate 
| predicate or predicate 
| expression list 
st 

expression list = expression { 


» » 


; Jempression} 


expression = | number 
| constant 
| id 


Mi pe mame. id { expression list)” 
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APPENDIX B8. DIAGRAMATIC REPRESENTATION OF PSDL 


The folowing diagrams present a tree structured breakdown of the PSDLlanguage 
as applied in the translator. Each section is numbered with a large arabic numeral inside 
a circle in the lower left corner. This is a “key” number. Transitions between “key” 
sections are marked as lines terminated with a capital letter and one or more “Key” 
numbers. For example, the non-terminal symbol, data tvpe, is found under “key” 
section I, as a possible representation of the non-terminal symbol, component. The 
transition to a section with more detail on data_tvpe is marked as B,3. This means go 
to the line marked B under “key” section 3. Moving to that section leads to the tree 
structured breakdown of the non-terminal svmbol, data tvpe, into the terminal symbol, 


TYPE, followed by the non-terminal svmbols, id, tvpe spec, and type impl. 


: psdl component 
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APPENDIX C. ADA SOURCE CODE IMPLEMENTATION OF VARIOUS 
PSDL CONSTRUCTS 


A. GENERIC QUEUE MODEL 


generic 
type ITEM is private 


package QUEUES is 
type QUEUE (Size : POSITIVE) is limited private; 
procedure CLEAR (TheQueue : in out QUEUE); 
procedure ADD (Theltem : in Item; 
ToTheQueue : in out QUEUE); 
procedure REMOVE (Theltem : out Item; 
FromTheQueue : in out QUEUE); 
OVERFLOW; 
UNDERFLOW : exception; 
private 
type LIST is array (INTECER range <>) of ITEM; 
type QUEUE (Size : POSITIVE) is 
record 
Mmaettems : LIST (0..Size); 
TheBack : NATURAL := 0; 
end record; 
end QUEUES; 


package body QUEUES is 


procedure CLEAR (TheQueue 
eueeOULUE) is 
begin 
TheQueue. TheBack := 0; 
end CLEAR; 


procedure ADD (TheItem : in ITEM; 
ToTheQueue : in out QUEUE) is 

begin 

ToTheQueue. Theltems(ToTheQueue. TheBack + 1) := Theltem; 

ToTheQueue. TheBack := ToTheQueue. TheBack + 1; 
exception 

when Constraint_Error => 

raise OVERFLOW; 

end ADD; 


procedure REMOVE (TheItem : out ITEM; 
FromTheQueue : in out INTEGER) is 
begin 
if FromTheQueue. TheBack = 0 then 
raise UNDERFLOW; 
else 
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Theltem := FromTheQueue. Theltems( 1); 
FromTheQueue. TheBack := FromTheQueue. TheBack - 1; 
end if; 
end REMOVE; 


D. GENERIC PACKAGES CONTAINING FIFO AND SAMPLED STREAM 
BUFFER TASKS 


l. FIFO Queue 


generic type JELEMENT TYPE is privater 
package FIFO is 
task FIFO_BUFFER is 
entry CHECK (NEW_DATA : out BOOLEAN); 
entry PUT (VALUE : in ELEMENT_TYPE); 
entry GET (VALUE : out EEEMENI gi wee: 
end FIFO_BUFFER: 
BUFFER_READ_ERROR, 
BUFFER_WRITE_ERROR : exception; 
end FIFO; 


package body FIFO is 
task body FIFO BUFFER is 
BUÜUEFER I TER 
VALUES ET LI ee 
NEW DATA VALUE : BOOLEAN := false; 
begin 
locp 
select | 
accept CHECK (NEW DATA VALUE : out BOOLEAN) do 
NEW DATA := NEW DATA VALUE; 
end CHECK; 
Or 
accept GET (VALUE : out ELEMENT_TYPE) do 
if NEW_DATA_VALUE then 
VALUE := BUFFER; 
NEW_DATA_VALUE := false; 
else raise BUFFER_WRITE_ERROR; 
end if; 
end GET; 
or 
accept PUT (VALUE : in ELEMENT_TYPE) do 
if not NEW_DATA_VALUE then 
BUFFER := VALUE; 
NEW_DATA_VALUE := true; 
else raise BUFFER_READ_ERROR; 
end if; 
end PUT; 
end select; 
end loop; 
end FIFO BUFFER; 
end FIFO; 
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2. Sampled Stream Queue 


generic type ELEMENT_TYPE is private 
package SANPLED is 
mask SAMPLED BUPFER is 
entry CHECK (NEW DATA : out BOOLEAN); 
entry PUT (VALUE : in ELEMENT TYPE); 
entry GET (VALUE : out ELEMENT TYPE); 
end SAMPLED BUFFER: 
end SAMPLED; 


package body SAMPLED is 
task body SAMPLED is 
ENSEER ELEMENT TYPE; 
MATOS : ELEMENT_TYPE; 
NEW_DATA_VALUE : BOOLEAN := false; 
begin 
loop 
select 
accept CHECK (NEW_DATA : out BOOLEAN) do 
NEW_DATA := NEW_DATA_VALUE: 
end CHECK: 
or 
accept GET (VALUB : out ELEMENT TYPE) do 
VALUE := BUFFER; 
NEW_DATA_VALUE := false; 
end GET; 
Or 
accept PUT (VALUE : in ELEMENT TYPE) do 
BUFFER := VALUE; 
NEW_DATA_VALUE := true; 
end POT; 
end select; 
end loop; 
end SAMPLED_BUFFER: 
end SAMPLED: 


C. GENERIC PACKAGE IMPLEMENTING TIMER 


generic 


with CALENDAR; 
use CALENDAR; 
package TIMER is 
Seartlime ; TIME; 
ReadTime : TIME; 
ElapsedTime : DURATION; 
TotalElapsedTime : DURATION; 
Run : BOOLEAN; 
end TIMER; 


with CALENDAR; 


use CALENDAR; 
package body TIMER is; 
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procedure START (Starilime: Coura 
Run : BOOLEAN); 
begin 
if not Run => 
StartTime := CLOCK; 
Run := True; 
end if; 
end START; 


procedure STOP (StartTime : in TIME; 
ReadTime : out TIME; 
ElapsedTime : out DURATION; 
TotalElapsedTime : out DURATION; 
Run : in out BOOLEAN); 
begin 
if Run => 
ReadTime := CLOCK; 
ElapsedTime := ReadTime StartTime; 
TotalElapsedTime := TotalElapsedTime "+" ElapsedTime; 
Run := False; 
end if; 
end STOP; 


"mM 


procedure READ (StartTime : in TIME; 
ReadTime : out TIME; 
ElapsedTime : out DURATION); 
TotalElapsedTime : out DURATION); 


begin 
ReadTime := CLOCK; 
ElapsedTime := ReadTime "-" StartTime; 


TotalElapsedTime := TotalElapsedTime "+" ElapsedTime; 
end READ; 


procedure RESET (Startlime : out TIND 
ReadTime : out TIME; 
ElapsedTime : out DURATION; 
TotalElapsedTime : out DURATION; 
Run : out BOOLEAN): 
begin 
StartTime := CLOCK; 
ReadTime := CLOCK; 
ElapsedTime := 0.0; 
TotalElapsedTime := 0.0; 
Run := False; 
end RESET; 
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APPENDIX D. PROGRAM LISTING FOR TILE TRANSLATOR 


The following is a listing of the Kodiyak input file which is compiled create the 
translator. It 1s composed of three sections delimited by the %% marker. Comments 
are indicated by the ! mark and extend to the end of the line. Backslash followed bv t 
or n follows the UNIX convention and stands for “tab” and “newline” respectively. 

The first part of the file is the lexical defimntion section. The various lexical tokeus 
ier OWL are identified. In order to assist this definition, classes of lexical characters can 
be defined. Such definitions are identified by the %define statement. Standard “Kleene” 
@l@sures are used throughout (1.c., {}+ indicates one or more, {}* indicates zero or 
mere), Ihe sohd vertical bar ( | } indicates an “or selection. The circumflex (shifted 
6) in the definition for Char (character) indicates “all symbols except those immediately 
following” (1.e., all except left and right curly braces). Left and right brackets between 
two words indicates they are to be evaluated together as a lexical token. 

The %% marker begins the second section. Here, the attributes for non-ternunal 
and some terminal symbols of the language are defined. Kodiyak allows either string 
or integer type attributes. In this case all attributes are string type. Each non-terminal 
(e.g., start) has one attribute, trn (shorthand for translation), of type string. All 
Kodivak translators have a start symbol which is used to indicate that the input file has 
been completely reduced and output can begin. Terminal symbols can also have attri- 
butes. In this case five terminal symbols have been assigned the special attribute 
“text. This attribute returns the value of the input text which the terminal symbol 
matched. 

Section three of the Kodiyak file begins with the secoud %% marker. It 1s a repre- 
sentation of the grammatical structure of PSDL. It begins with the start symbol. The 
start symbol cannot appear on the right side of any production rule. Ifit did, output 
would commence even though the parsing tree of the input file would not have been 
completely reduced. Each producton rule in the grammiar is represented and attached 


to each rule 1s an "attribute equation" surrounded by curly braces. The “attribute 
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equation" specifies what output 1s to be created when the corresponding PSDL pro- 
duction rule is reduced. Within the “attribute equation,” square brackets surrounding 
a series of items indicates the concatenation of the items. The solid vertical bar 1s used 
to indicate alternate possibilities for a given production rule. This is an exclusive or se- 
lection. It is also precedence ordered (1.e., top to bottom, the first rule which matches 
is the rule evaluated). Care must be exercised here as some states are implied and not 
explicit. For example, functionality has but one attribute equation. However, it has 
an implied emptv state, since all three of the non-terminal symbols which are part of the 
production rule for functionality can have an empty state. Recursion and optional cases 
are supported. The naming convention used in this translator is as follows: 

® opt_name means the item is optional 

e name 1 list means one or more of the item 


e name 0 list means zero or more of the item 


When compiled, a program of about 230 kilobytes in size is created. The compiled 
program is C object code. Certain features are incorporated in all products created with 
Kodivak. The executable code recognizes the standard UNIX -h, help, switch and re- 
sponds with the correct usage syntax and a listing of optional switches. The three most 


useful are: 
* -ooutfile name, allows the naming of a file to receive the output of the translator 
* -], causes the translator to display each PSDL token as it 15 recognized 


e -y, causes the translator to display each PSDL production rule as it 1s resolved 


The last two switches are especiallv helpful in debugging an input program. 


I definitions of lexical eTasses 


%define Digit am 

define Int ¡(Diet 

define Letter :[a-zA-Z_] 

“define Alpha : ((Letter)|(Digit]) 
define Blank SEND 

define Char Ero 

“define Quote E 


! definitions of white space 


: (Blankj* 
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! definitions of compound symbols and keywords 


GTE 

LIE 

NEQV 

ARROW 

TYPE 

OPERATOR 
GRECI ICATION 
END 

GENERIC 

INPUT 

OUTPUT 

STATES 
INITIALLY 
ENCEPTIONS 
Wes EXEC_TIME 
HEESWRESP TIME 
MIN CALL PERIOD 
MUCROSEG 

MS 

SEC 

MIN 

HOURS 

Bx 

KEYWORDS 
DESCRIPTION 
AXIOMS 
IMPLEMENTATION 
ADA 

GRAPH 

DATA STREAM 
TIMER 
CONTROL 
TRIGGERED 

ALL 

SOME 

PERIOD 
ANISH 
EXCEPTION 
READ 

RESET 

START 

STOP 

IF 

NOT 

AND 

OR 

TRUE 

FALSE 

ID 

SIRING LITERAL 
INTEGER. LITERAL 
REAL LITERAL 
NET 


: n. 
: "<= 
|n 1! 


1! 


Woy! 

: type| TYPE 

: operator|OPERATOR 

: specification|SPECIFICATION 

: end | END 

: generic|GENERIC 

: input| INPUT 

Nouspht| OUTPUT 

: States | STATES 

: initially|INITIALLY 

: exceptions | EXCEPTIONS 

:maximum[ Jexecution[ ]time|MAXIMUM[ JEXECUTION[ JTIME 
:maximum( ]response( ]time|MAXIMUM[ ]RESPONSE[ JTIME 
:minimum[ Jcalling[ Jperiod|MINIMUM[ JCALLING[ JPERIOD 
:microsec|MICROSEC 

: ms | MS 

: sec | SEC 

: min|MIN 

: hours | HOURS 

: by[ Jrequirements|BY[ JREQUIREMENTS 
: keywords | KEYWORDS 

: description|DESCRIPTION 

: axioms | AXIOMS 

: implementation|IMPLEMENTATION 

: ada| Ada|ADA 

: graph | GRAPH 

:data[ Jstream|DATA[( ]STREAM 

: timer| TIMER 

:control[ ]constraints|CONTROL[ JCONSTRAINTS 
: triggered| TRIGGERED 

: by[ Jall|BY[ JALL 

: by[ ]some| BY[ ]SOME 

: period| PERIOD 

: finish[ Jwithin|FINISH( JWITHIN 

: exception| EXCEPTION 

: read | READ 

: reset [RESET 

:start|START 

T SCOR STOP 

sic IP 

. Td: | "not" | CNOT 

ct | "and" | "AND!" 

a" | " | on | "oR" 

: true| TRUE 

: false|FALSE 

: (Letter (Alpha)* 

: {Quote}{Char}*{Quote} 


: (Ent: 
diate mt 
. n na (Chary*"" 
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! operator precedences 
! %left means group and evaluate from the left 


left OR; 

vede t AND; 

left NOT; 

Alert '<', TEI 


0/7 0/7 
¿0/0 


! attribute declarations for nonterminal symbols 


start ( trn; gj stEXDo 

pad trn; stain); 

component { tin: string, m; 

data type ( trm stering mi 
operator ( trm: scrin: m 

type spec ( trn: string; b 
opt.type decl LI list ( trm: "strime; 5 
type decl | list (trn: string S 
type decl cem string i; 

op spec OL list { ten strings. 
operator spec (trm: SErIng;, i 
interface (tin: strine S 
attrib O list { tram aten 
attribute ci trn: SUB, y. 
generic param ( trn: string; ) 
inpute {Pero a Serin; P 

OUEDUE ( Ech; String), 

states (ftri: String a 
exceptions ( trn: string; ) 
timing into ( trn: Strings, 
maxet { trn: string; }; 

maxrt (Otrnustrimso a. 

mincp (tens seria: 

time ern String. 

unit { seam: Sstrine ses. 

id lista Ern: strip NA 
opt_reqmts_trace { trn: string; }; 
reqmts_trace { trn: string; }; 
functionality (tri stem. 
opt L trn sering i: 
opt iüformal_ desc { Crn: ast tance: 
Opt formal desc "Era: stir, ); 
keywords { trn: string; }; 
infermal desc [ ton: v*strung.; |: 
formal desc ( trn: string; ); 
type impl ( tri: strine: a), 

op. impl O list ( tru: strings. 
operator. impl ( trn: string; ); 
pci amplo con; STI 

data flow diagram ( trn: string; ); 
link O list (strn: strin m; 
Tink (Stri: string m. 

opid (crn: string s 

opt_time { trn: string; ); 
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aBEEStreams ( trn: string; y) 

ODE cimers ( troi: string; L: 

ope control constraints (trn: string; ); 
streams ( trn: string; }; 

type name ( trn: string; }; 

timers { trn: string; }; 

@@mtrol constraints { trn: string; ); 
Monstraint O list { trn: string; }; 
BOnstraint ( trn: string; }; 
operator name ( trn: string; }; 

6pt trig { tro: string; ): 

Wet trigger ( trn: string; ); 
grosser [ trn: string; ); 

ooper { trn: string; 3; 

meetin w { trn: string; }; 
eure 0 list { trn: string; % 
cept 0 list { trn: string; ); 
Game O list { trn: string; }; 

Emer op { trn: string; ); 

Speer predicate { trn: string; }; 
mmedjcate branch ( trn: string; 3; 
predicate ( ten: string; ); 
expression list ( trn: string; }; 
EBENexpbression ( trn: string; }; 
expression_O_list { trn: string; }; 
expression { trn: string; }; 

mex op ( trn: string; T: 

Ecnstant [f trn: string; b 


! attrbute declarations for terminal symbols 


E text: string; }; 

E text: string; ); 
STRING_LITERAL{ %text: string; }; 
INTEGER LITERAL( %text: string; ); 
REAL LITERAL, text: string; ); 


0/0/ 
/0 10 


! psdl grammar 


start 
: psdl 
(cone putpsdi ten); } 


3 


psdl 
psdl component 
psa = [psalii2]. tía, component. tra]; } 


a ue 


we 
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component 


data type 

( component. trn - data type.trn; ) 
| operator 

{ component. trn = operator. trn; } 


data_type 
: TYPE ID type_spec type. Ri 
( data type. trn = [' type ", D. textu M type spec. trn, 


2 , type_ impl. ten, Wwe]: ) 


operator 
: OPERATOR operator_ name operator_spec operator_ impl 
{ operator. trn = [ procedure * operator name. trn, is; 
operator, spec. trn," Vn" ,operator. imp), trae E ) 


. 
3 


type spec 

: SPECIFICATION optstyvpe decl l-list oOpESDCONU „list functionality END 

[ type_spec.trn = [opt_ type_ decl. 1l list. trn, An ,op-spec SOM eM 
"An", functionality. ten. end; An"; ) 


“ 
3 


opt type decl 1 list 
type decl 1l list 
( opt.tvpe decl 1 list.trn = type decl 1l list.trn; ) 


( opt type decl l list ern = FIR 


3 


type decl 1 list 
type decl 1 list ',' type decl 
( type-dec] 1 Jist[l] trn = [type- decl. 1l lise". trn; 
Ep efe la MN 
| type_decl 
( type decl 1 list.trn = type decl.trn; ) 
type decl 
al list” type_name 
( type decl.trn - [id list.trn,":",type name.trn]; ) 


. 
3 


op spec, 0 list 
: op spec O0 list OPERATOR operator name operator. spec 
( op spec, 0 list[l]. trn - [op, spec 0 list[2] trn, An procedure E 
operator, name. D ds E 
Operator, spec. trn]; ) 


( op_spec_0_list.trn = ""; ) 
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operator, spec 
SPECIFICATION interface functionality END 
( operator spec.trn = [interface.trn, An”, 
functionality. trn,' end;in 9; ) 


e. 
3 


interface 
Atera D. O list 
nterface trn = attrib O list. trn; } 


. 
3 


Burrib O list 
attrib O list attribute opt reqmts trace 
marttrips0-list[l].trnmzUpdEEr OMS leen ope. reqmts_trace.trn]; } 


Matera Doc list. tin = eny 


. 
3 


attribute 
generic param 
{ attribute. trn = generic_param. trn; ) 
| input 
(ateribute) con = input. tra; } 
| output 
Mareribute. ten = output. trn; | 
| states 
[ attribute. trn = states. trn; ) 
| exceptions 
[ attribute. trn = exceptions. trn; ) 
bP timine into 
{ attribute. trn = timing_info.trn; } 


. 
3 


generic_param 
GENERIC type. decl 
( generic param.trn = [" generic in”,type decl. trn]; ) 


Input 

INPUT type_decl 

ape rn eq ind type deeltrn]j') 
Output 

OUTPUT type_decl 

Meueputsera = [i : out type decle tral 3 
states 


STATES type_decl INITIALLY expression_list 
[ states. trn = ['procedure PRELOAD is;in PUT (",type decl.trn, 
");\n" ,expression_list.trn]; } 
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exceptions 
- EXCEPTTIONS ciais E 
( excéptions. trn = ["raise exception “ddalist cn): ua 


1d St 
id list ',' ID 
( id list[1] trn z [id list]. ttn) TT 
| ID 
{- id_list[1]. trae CoL ON 
timing info 
: maxet 
( timing info.trn - maxet.trn; ) 
| mincp 
{ timing info trie — minco cena 
| maxrt 
{ Ciming info. Cins maxtor, 
maxet 
MAX EXEC TIME time 
[ maxet.trn =  time.trn; ) 
mincp 
MIN_CALL_PERIOD time 
[ mincp. trn = time. trn; ) 
maxrt 
MAX_RESP_TIME time 
tumaxrtotru = Came, crn. ? 
time 
INTEGER LCI TEKACMUNTE 
(cine trn = [INIEGER LITERAL text unit corno 
unig 
MICROSEC 
üxungt trn o M RA 
| MS 
(onie en = nc 
| SEC 
ünvtotrn = mnm 
| MIN 
(uno trn n 
| HOURS 


"n. 


( unit. trn - "An"; ) 


(ungtotzn - een 
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opt reqmts trace 
reqmts trace 
[ opt_reqmts_trace.trn = reqmts trace.trn; ) 
EU 
( opt reqmts, trace. trn 9 ''; ) 


e 
3 


reqmts trace 
D id list 
L reqmts_trace. trn = ""; } 


e. 
3 


Euuctionality 
opt keywords opt informal desc opt formal desc 
( functionality.trn - [opt keywords. trn,opt informal, desc. trn, 
opt formal desc. trn]; ) 


opt, keywords 


keywords 
L opt keywords.trn = keywords. trn; ) 


ter, 


( opt keywords. trn us 


3 


opt informal desc 
informal desc 
( opt informal desc.trn - informal desc.trn; ) 


( opt informal desc.trn = ""; } 
opt formal desc 


formal desc 
( opt formal desc.trn = formal desc.trn; ) 


Mont formal desc tr ; } 


keywords 

KEYWORDS id list 

( keywords. trn = "\n"; } 
informal desc 


DESCRIPTION TEXT 
@ontormal dese trn = '\n >} 


e 
3 


formal desc 
AXIOMS TEXT 
( formal desc. trn - NIME ) 


37 


type impl 
IMPLEMENTATION ADA ID 
type_impl.trn = [procedure ",ID.%text, ' is;\n ]; } 
| IMPLEMENTATION type name op. impl. OTIS END 
{ type_impl.trn = ["\n package DATA_ aT Y PES sis in” type name. trn, |n 
op impl 0 list. trn, eT 
"end; \n"]; } 


. 
3 


op impl O list 
op_impl 0 list OPERATOR Di name operator impl 
(op inps 0_list[1]. trn = 


( op impl O list(1]. trn s» ''5 ) 


e 
3 


operator_impl 
IMPLEMENTATION ADA ID 
L operator impl.trn = [ procedure ",ID.%text "ism uM E 
| IMPLEMENTATION psdl, impl 
( operator, impl.trn - [psdl, impl. trn]; ) 


e 
3 


psdl impl 
data flow diagram opt streams opt timers opt control constraints 
opt, informal desc END 
( psdl impl.trn - [data flow diagram. trn, "An" ,opt streams.trn, An", 
opt timers.trn, "Ag ,Omt controls constraints. t 
Pa donos orm! desc. trn," end;WMn"j ) 


. 
3 


data flow diagram 
GRAPH link. O. list 
{ data_flow_diagram. trn = ["\n-- Graphic representation: nce 
Link 0 senteron, n Du 


link_0_list 
liak 0 lise link 
( link O list[1].trn - [link _0_list[2] crn. Co mk d EDO, 


{ Janmk20_ list. treme c 


link 
ID opid ARROW ID 
( link. trn - [opid.trn, . ID2]. HHIH HUI 


opid 
ID opt time 
{ opid.trn = [IDiátext optlcime cera 
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opt time 
' time 


(opt. timestrn Mem era, An ); } 


ASIE ) 


("opE-time. trn 
) 
opt_streams 


streams 
{ DL streams. tri = streams. Crn; } 


( opt streams.trn = ""; ) 


3 


opt timers 
timers 
(ope timers. trn 


timers tern; } 
(ope cimers.trm— : 4 
y 


BEL control constraints 
Cone ro Constraints 
Copitacontrol conskrainis trn eontro E constraints. TIN; | 


opt control constraines corn = +.) 


streams 
DATA STREAM type decl 
{ streams. trn = [" task STREAM is new FIFO \n", 
e perdia n 
type_name 
TIE pe deci e 
(ene name ten = (1D. 2text (| evpeldeci 1 list, trn, Jin]; ) 
| ID 
( type name. trn = ID. %text; } 
timers 


DIMER cease 
{ timers. trn = [package ",id_list.trn,'' is new TIMER; \n''] ; } 
control_constraints 


CONTROL constraint_0_list 
{ control conserdintsitrn ~ constraint O listate; } 
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constraint. O list 
constraint 0 list constraint 
{ constraint 0 _listfl]. trn = [constraint O mE 
constresme. Ermo 
| 


{ constraint Uslistltin = E } 


3 


constraint 
OPERATOR operator name opt trig opt per opt fin w out O list 
except O list time O list 
{ constraint. trn = [" procedure ",operator name. trn,'An',opt trig. tl 
"\n' ,opt_per. trn,"\n" ,opt_fin_w. trn,"\n" ,out_0_list. ' 
An',except O list.trn, An”,time O list. Ema 


. 
3 


operator_name 


Ep e nan m iD 
( operator-name.tzn = [type_name. tea... ID teca 
| ID 


[ operator_name.trn = ID. %text; ) 


opt_trig 
TRIGGERED opt_trigger opt if predicate opt reqmts trace 
( opt trig.trn - [opt trigger.trn, Xn ,opt if predicate trm M 
opt regmts trace. rumen Ii) 
| 


(opt tris err 
3 
opt_trigger 


trigger 
{ Opt_trigger tin = Crigsger. Lan) 


{ opt telonero M 
trigger 
ALL id_list 
(trisser trn = | iF danse ci NN, 
| SOME dd lisit 
( trigger. trn = pe “dd listitrn, oa NN 
opt per 
PERIOD time opt reqmts trace 
( opt, per. trn - "An"; } 
{ opt perstrn =) T 


3 
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Spt finv 
FINISH time opt_reqmts_trace 


( opt fin w.trn = "\n"; } 
(opt-in v ea" = 
3 

Sut 0 list 


out 0 lrst OUIPUT Iid list opt 1£ predicate opt_reqmts_trace " 


( out 0 list[l] trn —» [out O0 list[2].trn," PUT ",id list.trn, ; 
opt if predicate.trn,'" ',opt reqmts, trace.trn]; ) 


{ out_O_list.trn = ""; } 


3 


except O list 
except O list EXCEPTION ID opt if predicate opt reqmts trace 
{ excepume list[lf. tin = [except O listlZj crn, RAISE "ID. text," ", 
open precjcite tm, | opt reqmts trace. trn]; 


( except 0 list.trn - "'; ) 


3 


time O list 
time O list timer op ID opt if predicate opt reqmts trace 
imenso NisEni ten = (time O list(2|.ctm, MME mer op. Crn," "T. 
Ios a *Epredicate.trn, An ", 
opt_reqmts_trace. trn]; } 


(seme Oslist.tri = "" 29} 
timer_op 
: READ 
( timer op.trn - ("READ ("] ) 
| RESET 
Meiner op crn = [RESET] 7 
| START 
(einer op. trn = STREE} 
| STOP 


MODE aT 


( timer, op.trn 
; 
opt if predicate 


IF predicate branch 
( opt if predicate.trn = ("if ",predicate branch.trn] | 


{opti s predicate: tram = cca 
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predicate branch 
: predicate AND predicate "prec AND 
( predicate, branch. trn - [predicate[l1] trn," AND ”, 
predicate[2] cena 
| predicate OR predicate %prec OR 
( predicate, branch. trn = [predicate[1].trn," OR ”, 
predicate[2]. trn] ; } 


| NOT predicate %prec NOT 
( predicate branch.trn - ["NOT",predicate.trn] ; ) 
| predicate 


( predicate branch.trn - predicate.trn; ) 


3 


predicate 
: expression 

( predicate.trn - expression.trn ; ) 

MA SE 

( predicate.trn 


[ID Eexte : gd DE PIENE 


3 


expression list 
Opt, expression 
( expression list.trn - opt expression.trn; ) 


e 
3 


opt expression 
expression ',' expression 0 list 


(opt expression. trn. [expression. trn," 


, expression 0 listotruni 
( opt expression.trn = ""; } 
; 
expression O list 
. . t e 
expression 0 list ',' expression 
tt 


( expression O list[1].trn * [expression 0 list[2] trn) MD 
expression.trn] ) 
| 


(expression 0 list.trn = "'; ) 


expression 
operator name '(' ex ression list E 


[ expression. trn = [' "operator. name. trn, 
pression list. tri, Dna 
| Operator_name ‘=' constant “prec LIE 
(expression Ci =i operator nane. trn, = ,constant-trn, \n bh ) 
| operator_name '<' constant *prec LIE 
WE press ion cn fon -cator name. trn, < constar. time n |; } 
| operator name '»' constant %prec LTE 


"“eoncwent. tin, nj; } 


{ expression. trn = [operator_name. temp” > 
| operator_name infix_op constant 
( expression.trn - [operator name. trn," a K oE den, ", 
OE 1 


| constant 


{ expression. trn = constant.trn; } 
| operator_name 
{ expression. trn 


(" = " operator_name.trn,'; An”); 


mr ix Op 
: GTE “prec GTE 
( infix op.trn = ">="; ) 
ETE %prec LTE 
Ao». tin = >=, ) 
| NEQV "prec NEQV 
{ infix_op. trn = /- } 
constant 
RUE 
Meens tant+ten = true ;,} 
le FALSE 
( constant. trn = "false"; ) 


| INTEGER LITERAL 

( constant. trn = INTEGER LITERAL. text; ) 
| REAL LITERAL 

( constant. trn = REAL LITERAL. %text; } 
| STRING LITERAL 

( constant. trn = STRING LITERAL. $text; ! 
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APPENDIX €. PROGRAM LISTING FOR TEST PROGRAM IN PSDL 


The following test program is taken from the Ph.D. dissertation by Luqi which first 
described PSDL [Ref. 19]. It 1s representative of most features in the PSDC Jansen 
It contains descriptions at several levels of decomposition of the proposed svstem. The 
system envisioned is an embedded computer systein for a medical treatment instrument 
known as a hyperthermia system. [t implements real-time control constraints (required 
for safetv of the patient as well as ensuring correct application of the theraputic tech- 
nique). The system described would monitor and control the operation of a inicrowave 
generator. The mucrowave generator would be used to generate a hypertherinia condi- 
tion for the treatment of tumors in the brain. There is a critical temperature range which 
would provide proper theraputic effect and vet remain safe for the patient. The system 
has stringent shutdown time limits when either treatment is completed or the temper- 
ature of the target tissues exceeds a limiting value. Obviously, there could be severe 
penalties should the system fail to function correctly. The time limits on startup and 
shutdown and the precise timing of the treatment period are critical. Maintenance of 
nucrowave power levels is critical to ensure correct temperature is maintained within a 
narrow range. As such, this program: illustrates many of the features of an embedded 
system with real-time constraints. Since the program utilizes most of the features of 
PSDL and is a real-time system, it is a convenient one to utilize to test the translator. 
The Ada code produced thus far is elementary at best. As noted in the conclusion for 
this paper, the formal relationship between PSDL and Ada must be established and 
applied to the translator to ensure generality and correctness. Further, there is no li- 
brary of reuseable Ada software modules from which to draw implementation code for 
the various parts of the hyperthermia system. The implementation code for this svtem 
would require developinent. The translator provides (as intended) interconnection code 


for the software. 


OPERATOR brain_tumor_treatment_system 
SFPECTEICATIFON 
INPUT patient chart: medical history, 
treatment switch: boolean 
OUTPUT treatment finished: boolean 
STATES temperature: real 
INITIALLY 37.0 
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DESCRIPTION 
( The brain tumor treatment system kills tumor cells 
by means of hyperthermia induced by microwaves. 


END 


IMPLEMENTATION 
GRAPH 


DATA STREAM treatment power: real 
CONTROL CONSTRAINTS 
OPERATOR hyperthermia system 
PERIOD 200 BY REQUIREMENTS shutdown 
OPERATOR simulated, patient 
PERIOD 200 
DESCRIPTION { paraphrased output } 
END 


TYPE medical_history 
SPECIFICATION 
OPERATOR get_tumor_diameter 

SPECIFICATION 

INPUT patient chart: medical history, 

Cunorelocation string 

OUTPUT diameter: real 

EXCEPTIONS no tumor 

MAXIMUM EXECUTION TIME 5 ms 

DESCRIPTION 

( Returns the diameter of the tumor at a given location, 

produces an exception if no tumor at that location. 


END 


KEYWORDS patient, charts, medical records, treatment, records, 
lab records 
DESCRIPTION 
( The medical history contains all of the disease and 
treatment information for one patient. The operations 
for adding and retrieving information not needed by 
the hyperthermía system are not shown here. 


END 


IMPLEMENTATION 
tuple [tumor desc: map[ from: string, to: real], ... ] 


OPERATOR get_tumor_diameter 
IMPLEMENTATION 
GRAPH 


DATA STREAM td: tumor_descr 
CONTROL CONSTRAINTS 
OPERATOR map. fetch 
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EXCEPTIONS no tumor IF not(map.has(tumor location, td)) 
END 


END 


OPERATOR hyperthermia system 
SPECIFICATION 
INPUT temperature: real, patient chart: medical history, 
treatment switch: boolean 
OUTPUT treatment power: real, treatment finished: boolean 
MAXIMUM EXECUTION TIME 100 ms 
BY REQUIREMENTS temperature_tolerance 
MAXIMUM RESPONSE TIME 300 ms 
BY REQUIREMENTS shutdown 
KEYWORDS medical_equipment, temperature_control, 
hyperthermia, brain_tumors 
DESCRIPTION 
( After the doctor turns on the treatment switch, the 
hyperthermia system reads the patient's medical record 
and turns on the microwave generator to heat the tumor 
in the patient's brain. The system controls the power 
level to maintain the hyperthermia temperature of 
42.5 degrees C. for 45 minutes to kill the tumor cells. 
When the treatment is over, the system turns off the 
power and notifies the doctor. 


END 


IMPLEMENTATION 
GRAPH 


DATA STREAM estimated power: real 
TIMER treatment, time 
CONTROL CONSTRAINTS 
OPERATOR start up 
TRIGGERED IF temperature < 42.4 
BY REQUIREMENTS maximum_temperature 
STOP TIMER treatment_time 
RESET TIMER treatment_time IF temperature <= 37.0 


OPERATOR maintain 

TRIGGERED IF temperature >= 42.4 
BY REQUIREMENTS maximum_temperature 

START TIMER treatment_time 
BY REQUIREMENTS treatment_time, temperature_tolerance 
OUTPUT treatment_finished IF treatment_time >= 45 min 
BY REQUIREMENTS treatment_time 

END 
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OPERATOR start up 
SPECIFICATION 
INPUT patient chart: medical history, temperature: real 
OUTPUT estimated power: real, treatment finished: boolean 
BY REQUIREMENTS startup time 
MAXIMUM EXECUTION TIME 90 ms 
BY REQUIREMENTS temperature tolerance 
DESCRIPTION 
( Extracts the tumor diameter from the medical history and 
uses it to calculate the maximum safe treatment power. 
Estimated power is zero if no tumor is present. The 
treatment finished is true only if no tumor is present. 


END 


IMPLEMENTATION Ada start up 
END 


OPERATOR maintain 
SPECIFICATION 
INPUT temperature: real 
OUTPUT estimated, power: real, treatment finished: boolean 
fees IMUM EXECUTION TIME. 90 ms 
BY REQUIREMENTS temperature_tolerance 
DESCRIPTION 
( The power is controlled to keep the power between 42.4 
and 42.6 degrees C. 


END 


IMPLEMENTATION Ada maintain 
END 


OPERATOR safety_control 
SPECIFICATION 
INPUT treatment_switch, treatment_finished: boolean 
estimated_power: real 
OUTPUT treatment_power: real 
BY REQUIREMENTS shutdown 
MESSEMUM EXECUTION TIME 10 ms 
BY REQUIREMENTS temperature_tolerance 
DESCRIPTION 
( The treatment power is equal to the estimated power 
if the treatment switch is true and treatment finished 
is false. Otherwise the treatment power is zero. 


END 


IMPLEMENTATION Ada start_up 
END 
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